>> Hi. >> >> I know about several discussions about pre-up and pre-down in the past. >> Dan, I understand your position and I can follow your arguments against. > > Yes, I realize there are use-cases where such operations would be nice > to have, and I'm open to it. I haven't gotten around to reviewing the > patch yet though, and it's a fairly major change to the flow of things > so it's not something to be undertaken lightly. > >> But I see a number of usecases where I dont have any idea instead of >> doing >> it with pre-up / pre-down scripts in nm-dispatcher. I know every script >> in >> these phases is a potential risk for nm functionality. From nm site you >> have no chance to control those scripts and it might be that users will >> come up with problem reports that are based on their own scripts. >> >> For example. We need to find solutions for these problems: >> 1. unmount cifs shares before a connection becomes disconnected > > Right, but remember that this is only possible *sometimes*. There will > always be times where the connection just died and no clean > disconnection is possible. I know. The example was using mounts over wlan. Bad Idea. Let's talk about
Ethernet and laptops. Laptops can be either in a docked environment where the Ethernet cable is in the dock or they are direct connected. So what we would like to do is: automatically unmount existing mounts using acpi undock event based scripts (user has to press the dock button), unmount in the case a user suspend his laptop, or undock in pre-down phase. So if the user decides to unplug the Ethernet cable from his laptop **before** disconnecting from the network he has to live with a hanging system. We told him before. > But in cases where it's possible to do so, > we should probably try to give these operations at least a few seconds > to complete before killing the connection. Ok, if you are saying "a few seconds" then users should be able to configure the value for this in the global configuration. >> 2. stop any other active connection when a user select another one (maybe >> this can also be done in down event) to make sure the system is single >> homed > > I don't really see the value of this actually. In practice, the > multi-homing is not an issue and it should be transparent. Multi-homing > is also required for less interruption in network connections. If you > had to wait 30 seconds to connect to a wifi access point after > unplugging a cable every time, that's annoying. I'll also note that > Windows and Mac OS X have been multi-homed by default for years. > Yust one example: A user connects to 3g with his internal modem. The signal is bad and he decides to connnect via bluetooth cell phone (he can put it on a windowsill to get a better signal). So he has two ppp based connections active. How do we control that the bluetooth based is the preferred? >> 3. disconnect from the active vpn before the underlaying connection >> becomes disconnected > > Yes. > >> 4. start replication of the mail client before really disconnecting > > Yes, though this has the potential to take a really long time. How long > do we give something like this? I'm not sure I see a usable way to do > this sort of thing if you have say some megabytes of mail to pull over a > slow connection, for example. It might work some places, but certainly > not many other places like 3G connections. That's why I would do it only in Ethernet based connections > This one needs more thought > about what the workflow would be like. How does the user indicate their > desire to disconnect? How do we know how long they are willing to wait > before they really do want to take their laptop with them? etc. > >> Maybe I'm off the track looking fixed to pre-up / pre-down as solution >> for >> these problems. If so please point me onto the right way. > > Most of these are pre-down really; the major use-cases I've seen for > pre-up have been stuff like captive portal login scripts. I went > through all the pre-up and pre-down scripts in an Ubuntu install last > year, and 80% of them were completely bogus things like munging the wifi > attributes, or working around out-of-kernel wifi driver bugs, or other > stuff that no longer needs to be done. But there are some valid cases > like you suggest. > I'm really sure that I could give you a number of interesting use-caes but therefore it's necessary to have the whole picture about what we are doing. I can tell you: it's exciting... > Dan Hans-Gerd _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list