Network Manager

[Lionel Dricot (aka Ploum)]

Hello,

I will not be a great help but I just want to thank you for this wonderful
work ! You are my hero ! ;-)

As I was talking about NM in a previous thread, I just want to add that :

- I've a bug whick I think is the unfamous atheros one : My connection seems
to be disconnected for 2 seconds every 3-4 minutes. I didn't saw it until I
try to play Enemy Territory, where a 3-4 seconds freeze is fatal ! ;-)

- I reported the following bug upstream :
http://bugzilla.gnome.org/show_bug.cgi?id=331529   It's IMHO an important
issue.

Have a good day

Ploum

On 17/02/06, Scott James Remnant <keybuk at gmail.com> wrote:
>
> (Note: I'm currently changing ISPs, thus the unusual e-mail address
> and lack of signature.  Please also Cc me on replies, as I'm not
> subscribed to the list and am just reading via the web-interface.)
>
> I've just uploaded a version of NetworkManager that implements the
> network-magic specification (http://wiki.ubuntu.com/NetworkMagic).
> This e-mail is to serve as both a rationale for the changes that have
> been made and to start a discussion about the ultimate destination of
> this package.
>
>
> First off let's outline the requirements we had:
>
> (a) it should not introduce any major new dependencies, and
> especially not introduce any new open ports.
>
> (b) where possible it uses our existing tools and daemons, especially
> the ISC dhcp3 client (dhclient3) instead of a different tool such as
> pump.
>
> (c) it integrates and interoperates well with our existing "ifupdown"
> infrastructure.  That allows configuration of interfaces in the
> /etc/network/interfaces file either by hand or through the
> gnome-system-tools "Networking" dialog.  Interfaces are brought up at
> boot time and when the hardware drivers are loaded automatically if
> they are marked "auto" in the file.  This system allows configuration
> of both static interfaces and DHCP interfaces.
>
> (d) scripts can be run when network interfaces are brought up and
> down, such as ntpdate; and if possible without having to duplicate the
> locations for them.
>
> (e) be reliable and not cause additional complications.
>
>
> The changes we made for each of the requirements and rationale are as
> follows:
>
> (a) Network Manager depends on the ISC bind9 name service daemon and
> reconfigures the machine to use the local name server, adjusting the
> name server configuration to forward to the appropriate DNS servers.
> This not only introduces a major new dependency, one which listens on
> network sockets, but also would prevent users from having a different
> DNS server on their system.  We've already undertaken a lot of work to
> remove any MTA from our system, so introducing something as major as a
> DNS server seemed like a backward step.
>
>      Instead we've applied a patch to the libc which causes
> /etc/resolv.conf to be reloaded whenever it changes under a running
> application.  This takes care of the issue of DNS information changing
> during the lifetype of such applications.
>
>     As we've already ensured that /etc/resolv.conf is modified and
> replaced correctly by dhclient, there was no need for Network Manager
> to try and maintain it itself; a source of several open bugs.  We've
> therefore also removed the "named-manager" from n-m entirely.
>
>      Unfortunately the "vpn-manager" had heavy dependencies on the
> named-manager, so this had to be removed as well.  VPN support wasn't
> a use case we've considered for dapper, where we're concentrating only
> on improving existing functionality and not necessarily introducing
> new functionality.  Also the VPN support in Network Manager was
> largely hidden, and has been vastly changed upstream in CVS anyway.
> It's inclusion can be reconsidered for dapper+1.
>
> (b) this was easy to accomplish, the dhcdbd daemon has been made to
> control dhclient and use the same PID and leases files that we use
> already.  This daemon responds to the same dbus messages Network
> Manager sends.
>
> (c) The problems here are that ifupdown and Network Manager have
> fundamentally different use cases.  ifupdown's goal is to keep all
> interfaces up all of the time, where Network Manager's is just to keep
> one up at a time.  Typical behaviour with both fighting ends up
> something like:
>
>         - udev starts: configures eth0 and starts dhclient3 to manage it
>         - dbus (and n-m) starts: deconfigures eth0, leaves dhclient3
> running (or kills it)
>         - user logs in
>         - nm-applet starts: configures eth0 again, and starts dhclient3
> again
>
>      This may initially seem merely irritating, but there's a lot of
> additional configuration option with the /etc/network/interfaces file
> -- such as wireless channels and mode that Network Manager would then
> fail to take into account.
>
>      We therefore decided that it would be best if Network Manager
> ignored interfaces completely if they were "manually configured" in
> /etc/network/interfaces.  This means you need to remove the
> configuration for them before you can use NM with them.  While this
> has an initial configuration difficulty, the general experience once
> configured is nicer.
>
>      This also removes some of the problems with static interface
> configuration; as currently Network Manager has no UI for configuring
> network interfaces, whether dynamic, static, or otherwise.
>
>      Currently however this patch has resulted in Network Manager
> simply not knowing about such interfaces, and it'll claim that no
> interfaces are configured when it should at least show the status of
> the configured interface and not allow changing of them.  I intend to
> improve this if possible before release.
>
> (d) Network Manager includes a "Dispatcher" dbus service that listens
> to messages from the daemon proper and runs scripts in
> /etc/NetworkManager/dispatcher.d for those events.  We've modified
> this to include additional events (before an interface comes up, and
> after it has been taken down), and also changed it such that it
> instead causes the scripts in /etc/network/if-*.d to be run instead.
>
>      Thus it interacts reasonably well with the existing scripts there.
>
> (e) is probably the largest problem.  With the most modern wireless
> cards and drivers (which is currently the largest reason for using
> it), Network Manager generally works well.
>
>      However with less main-stream drivers, including Atheros cards
> (which are a fairly popular 802.11g card) and most USB adapters, our
> testing has indicated a wide range of problems.  Some simply fail to
> be detected, some fail to scan, some fail to connect, etc.
>
>      Network Manager also seems to behave very poorly if there are
> multiple wireless interfaces, and seems to often try to configure the
> wrong one.
>
>
> So that's the requirements, changes and rationale.  Now we can decide
> what we want to do with it.  The options are simple:
>
> (1) leave it in universe for dapper
> (2) move it to main, but only on the archive so people can install it
> if they want it and get security support
> (3) move it to main and the ship seed, so that it's available on the
> CD for people who want it
> (4) move it to main and install by default in the desktop seed
>
> There's also the option for the LiveCD of having it installed by default
> there.
>
> My current feeling is that with the above modifications it can be
> installed by default, as it needs manual work to activate, but only if
> we provide some easy way to make that happen with a clear notice that
> it might not work.
>
> I'd probably rather it were in the ship seed, so those who know about
> it can install it, and those who don't won't experience any
> regressions.  We should probably install by default on the LiveCD.
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060217/1c2dfe21/attachment-0001.htm