Re: NetworkManager-Ddispatcher preup / predown

[Dan Williams <dcbw redhat com>]

On Thu, 2010-03-25 at 20:32 +0100, van Schelve wrote:
> >> 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.

Yeah, that's fine.  But remember, there's no really good way right now
to say "undock me".  Some docks have a button you can press to undock
with a LED that turns green when you can do so (which sends an ACPI
message to the OS probably), but I'm pretty sure Linux doesn't catch
that sort of thing.

So what you really mean here is that before undocking, the user has to
manually disconnect the ethernet connection from the menus.  Right now,
that calls the Disconnect() method of the device, and that device will
no longer automatically connect to *anything* until the user tells it to
do so again, even if there are carrier events.  This isn't optimal
interaction for dock/undock, but perhaps if we could get dock/undock
events from the OS we could handle this intelligently.

Otherwise we have no way to figure out what the intentions are, since
the whole reason Disconnect() was added in the first place was for users
who did want to place the device into a pseudo "manual" mode.

> > 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.

Possibly; but ideally we choose a high enough value that it catches most
cases, and a low enough value that it doesn't affect latency.  I don't
have a lot of sympathy for scripts that will take more than 20 or 30
seconds to do whatever they want to do; if they take that long, somebody
needs to think of a better way to accomplish that task.  In the mail
case that might mean syncing mail as  much as possible *while you're
connected*, and then only finishing one or two tasks during the
disconnect script, instead of trying to sync everything during the
pre-down script.

> >> 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?

Bluetooth will never be connected automatically, because we can't scan
for the remote device.  Scanning takes a long time, uses lots of power
with Bluetooth, and interrupts existing connections like headsets (and
also interferes with WiFi and WiMax, lowering your signal strength).

Thus, this won't be a problem.  User disconnects the internal modem from
the menu by choosing "Disconnect", ensures his/her bluetooth is
available on the phone, and chooses the phone from the menu.

Dan

> >> 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