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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list