Re: NM do not see any network

[Dan Williams <dcbw redhat com>]

On Thu, 2006-12-07 at 21:57 -0500, Darren Albers wrote:
> On 12/6/06, Darren Albers <dalbers gmail com> wrote:
> > I'll check out launchpad tonight and see what bugs are filed and also
> > look at what patches have been applied to the package and see if I can
> > correlate any of them to the recent problems people have reported.
> >
> 
> Looking over launchpad last night I see basically the same bugs
> repeated over and over regarding specific wireless cards but I did not
> see this specific issue.
> 
> I also looked at the patches and there are 9 patches applied to the
> base 0.6.3 tarball.  I am not sure why Ubuntu is not at 0.6.4 but I
> think the maintainer may not have had the time between Dapper and
> Edgy.
> 
> The patches seem relatively minor (Though I am probably not a good
> judge of that ;-) ) I can post all the patches if someone would like
> me to.
> 
> Here they are in summary:
> Supplicant timeout patch:  Increases the timeout when trying to
> associate to 60 seconds.

Somewhat bogus, increasing timeouts is the wrong thing to do...

> dbus_access_network: adds the user haldaemon to Networkmanager.conf

Debian specific, since debian uses groups to determine capabilities.  In
Fedora and SUSE this functionality is provided by pam_console and the
"at_console=True" tag in the NM dbus conf file.

> if_fix: adds #define _LINUX_IF_H
> resolvconf patch: changes the function
> nm_system_should_modify_resolve_conf to return false in
> src/backends/NetworkManagerDebian.c
> dispatch_more_events: Seems to add pre-up and post-down events to
> dispatcher.d  Wasn't this always an option?  Maybe what someone asked
> earlier about running a command before an interface is activated is
> possible with dispatcher.d with this patch?

Interesting; these events are quite a bit less interesting than it may
seem.  'pre-up' would be time-bounded, since NM certainly doesn't call
out to synchronous, blocking scripts when it brings up a connection, nor
should it.  So whatever script gets called here for pre-up will have to
be pretty fast, because NM isn't going to wait for it before continuing.
This is quite racy and therefore wrong.

I'm not sure what "post-down" means; there's already the disconnected
event from the dispatcher which executes scripts when the connection is
terminated.

> disabled_devices: This tells NM not to touch devices managed in
> /etc/network/interfaces

Right; everybody does this and that's fine; but Ubuntu seems to do it
automatically without telling users what's going on.  SUSE has a config
option in YAST, and half the questions we get here are about this
problem in Ubuntu, because people don't realize that touching something
in a config tool there turns something else off in NM.

> rml_wpa_workarounds: Robert's "famous" wpa workarounds patch  ;-)
> hostap-supplicant-driver: adds a workaround for the hostap driver

What does this one do?

> dbus 0.9: Changes dbus_connection_disconnect to dbus_connection_close ?

Yes, this is legit and should be in CVS.  I think it may have already
been committed to HEAD.

> I saw in the release notes for Feisty beta (I forgot the catchy code

Feisty Fawn Herd 1 :)

> name they used) that NM might be the default network management
> utility for Feisty so I think the testing period there will hopefully
> shake out any issues with their packages and maybe (hopefully?) will
> get some patches sent upstream.

Hmm, I thought Ubuntu was still punting NM-by-default since it doesn't
cover a bunch of use-cases like static IP.  That's fine, Fedora doesn't
turn it on by default either for that same reason.  SUSE's out in front
a bit here, which actually helps everyone out by exposing issues and
problems.

Dan