kozz at pegasos.org
Fri Feb 17 20:08:36 GMT 2006
I have the same problem, but changing "Wireless Network Discovery" from
"Always Search" to "Search Only When Disconnected" solves the problem. At
least for me.
On Friday 17 February 2006 20:56, Lionel Dricot (aka Ploum) wrote:
> 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
> Have a good day
> 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
More information about the ubuntu-devel