Re: NM post-connect hooks?

[Dan Williams <dcbw redhat com>]

On Mon, 2009-10-05 at 19:41 -0400, C. Scott Ananian wrote:
> We'd like to run some hook function after NM thinks the connection is
> 'connected' and before it reports the 'connected' status to NM
> clients.  In particular, we find that our users try to connect to
> broken networks of some sort or another with no way to reach the
> outside world, even though NM reports 'connected'.  We'd like to do
> some simple sanity checks on the network before NM tells xulrunner,
> our application, etc that we're got a valid connection.
> 
> I looked through the NM 0.7.1 source code, and there's nm-dispatcherd
> and a number of 'action' hooks in callouts/ -- can anyone tell me if I
> could use this mechanism to do the thing I describe above?  We've
> already got nm-dispatcher.d hook functions to run ntpdate, etc, but
> what I want is for NM to use the return code of my hook to affect the
> connection state, and I don't think nm-dispatcher.d does that.  Any
> ideas?

So the reason there are post-connect-but-before-NM_STATE_CONNECTED hooks
is because those scripts could take a significant amount of time,
especially in the case of badly coded scripts.  I posted mail from back
in August about the post-up/pre-down script, which is essentially what
you're looking for.  The ideas there revolved around bounding the
running time of post-up/pre-down scripts to ensure that user experience
was not screwed all to hell, and that NM wouldn't get loads of bug
reports from shitty scripts.  Sort of like the Firefox javascript "This
script sucks and is draining your battery" dialog, except without the
dialog.

Ideally this sort of thing would go in the NMConnection object in
backing storage to be saved with the connection, but that's got huge
security issues, so it's probably best done in the dispatcher.

Two reasons NM doesn't current implement the "am I really connected to
teh intarwebs" thing are that (a) we should be DoS-ing somebody's server
(a-la the DLink NTP fiasco a few years back) , and (b) there are quite a
few legit cases where you aren't connected to the outside world.

Next, a lot of the stuff people do in post-up and pre-down scripts can
be legitimately done otherwise, either through the normal NM config
(like routing table additions) or dispatcher scripts (where the
operations don't actually need to block connection completion).  That
said, this is the sort of use-case that's actually legit.

So here's how you'd go about doing this.  The dispatcher is currently
run async and its result is ignored.  First, you need to fix up the
dispatcher to not return the dbus action method until all the scripts
have completed.  Next, you need to fix up the dispatcher to terminate
long-running scripts (say, 5 seconds or more) and log that to syslog so
we know what the problem is.  Next, the NM dispatcher calling code
should take a callback which is called when the dispatcher is done, or
NULL to ignore the result.  We'd ignore the result in all cases except
for a new action you define called "pre-up".

The, you pull the state change to ACTIVATED out of
nm_device_activate_stage5_ip_config_commit() adn instead, kick off the
pre-up dispatcher and give it a callback.  When the callback runs, then
you transition to state ACTIVATED, or if you determine failure of the
dispatcher run, FAILED.

Which reminds me, we probably need much finer grained failure for the
dispatcher.  For example, if D-Bus is preventing it from running, we
probably don't want to consider that a hard failure.  But in your case,
you'd probably want to fail the connection entirely if you can ping
connected.litl.com or something.  So maybe if a pre-up script returns !
0, the dispatcher fails and NM fails the connection, but if there's a
failure running the dispatcher we dont' fail the connection.  Whatever.

In the end, not really that hard to do.  It's all about the timing.  How
long do you expect users to wait for the connection (when your ping
script is running) before it connects?  Remember, this is going to
happen when the driver craps out and NM tries to reconnect
automatically.  So it's important to make sure that we're not waiting
too long on stuff or the user experience suffers.

Dan