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 : <a href="http://bugzilla.gnome.org/show_bug.cgi?id=331529">http://bugzilla.gnome.org/show_bug.cgi?id=331529</a>   It's IMHO an important issue. Have a good day Ploum <div>On 17/02/06, Scott James Remnant <<a href="mailto:keybuk@gmail.com">keybuk@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> (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 (<a href="http://wiki.ubuntu.com/NetworkMagic">http://wiki.ubuntu.com/NetworkMagic</a>). 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 <a href="mailto:ubuntu-devel@lists.ubuntu.com"> ubuntu-devel@lists.ubuntu.com</a> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a> </blockquote></div>