On 12/8/06, Dan Williams <[EMAIL PROTECTED]> wrote: > On Thu, 2006-12-07 at 21:57 -0500, Darren Albers wrote: > > 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.
I see what this does (whether this is smart or not is beyond me...), the package adds a script to dispatcher that users these two new events to call the general networking configuration items that are required by Ubuntu. For example pre-up is used to trigger a script that calls the standard networking scripts for Debian/Ubuntu: The first sets some wireless options using the wireless tools and the second starts wpa_supplicant. The postdown does the opposite and shutsdown wpa_supplicant and then sets all the wireless configuration options to their defaults again. I think this is done so that people can set some specific items in /etc/network/interfaces such as speed, channel etc.. but as long as they keep the interface set to use DHCP Network Manager will continue to manage it. Could this be a potential problem for Network Manager if things like the rate are set there? > > > 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. I agree and I wonder if until the recent announcement that they really wanted people to use NetworkManager? Their point was probably that rewriting the gnome-network-panel to inform the users of this was too much work to make it by release or that there was nobody who wanted to take it on. > > hostap-supplicant-driver: adds a workaround for the hostap driver > > What does this one do? If it detects any of the following kernel_drivers hostap_pci, hostap_cs, and hostap_plx it passes hostap to wpa_supplicant. > > 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. Here is the spec they plan on implementing: https://blueprints.launchpad.net/distros/ubuntu/+spec/network-roaming It seems very redundant to 0.7 which I thought would be out with plenty of time for Feisty April release date... Is 0.7 still on track for Jan? On a side note I used Fedora for the first time on a Mac Mini my wife gave me for my birthday (I really tried to like MAC OS but little things kept annoying me about it) and I was impressed. It shows a lot of polish and there were some things that I really liked about it and it will probably stay since my needs on that system are a lot less than on my laptop so I won't need to learn all the nuances of another distro. _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
