Network Manager

[Emanuel Steen]

Hi,

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.

// Kozz


On Friday 17 February 2006 20:56, Lionel Dricot (aka Ploum) wrote:
> 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