On Thu, 2006-12-07 at 21:57 -0500, Darren Albers wrote: > On 12/6/06, Darren Albers <[EMAIL PROTECTED]> 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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
