powerd-dbus network extension

[Paul Fox]

hi daniel --

daniel wrote:
 > Hi Paul,
 > 
 > For 11.3.0 I'd like to implement a solution for the issue where powerd
 > idle-suspends while wifi connections are being established, causing
 > connection failures and other undesirable activity.
 > 
 > The solution I'm thinking of isn't ideal in that it adds a mini-daemon
 > alongside powerd. But hey, you just got rid of HAL, we have breathing
 > space ;) and I can't think of a better way.
 > 
 > Here is what I've thought up:
 > 
 > 
 > Instead of being on-demand and short lived, powerd-dbus will be
 > launched by powerd and will become a full-time daemon.
 > In addition to the functionality that it already has, it will connect
 > to the dbus system bus and monitor NetworkManager's StateChanged
 > signals.
 > 
 > The NM states are:
 > DEVICE_STATE_UNKNOWN = 0
 > DEVICE_STATE_UNMANAGED = 1
 > DEVICE_STATE_UNAVAILABLE = 2
 > DEVICE_STATE_DISCONNECTED = 3
 > DEVICE_STATE_PREPARE = 4
 > DEVICE_STATE_CONFIG = 5
 > DEVICE_STATE_NEED_AUTH = 6
 > DEVICE_STATE_IP_CONFIG = 7
 > DEVICE_STATE_ACTIVATED = 8
 > DEVICE_STATE_FAILED = 9
 > 
 > Lets assign a variable:
 >   nm_suspend_ok = state <= 3 && state >= 8

since that can't be true, i assume you meant:
    nm_suspend_ok = state <= 3 || state >= 8

 > (i.e. suspend is only OK if we aren't establishing a connection)
 > 
 > It will also monitor the wpa_supplicant signals for the same device,
 > watching for the Scanning signal.
 >   wpas_suspend_ok = !Scanning
 > 
 > Finally:
 >   suspend_ok = wpas_suspend_ok && nm_suspend_ok

you're far more familiar with the details of how NM and wpa_supplicant
operate, so i'm sure your proposed conditions are likely correct.

 > When the suspend_ok flag changes, it would be communicated to powerd
 > through the powerevents socket, as "network_suspend_ok" or
 > "network_suspend_not_ok".
 > 
 > There would be a 2 second settle period after a not-OK to OK
 > transition before sending the powerd event (and the event would be
 > aborted if the situation changes within those 2 seconds). This
 > captures the case where NM says the device is disconnected, and
 > wpa_supplicant has finished a scan (suspend_ok == TRUE), but NM will
 > initiate a connection immediately after (once it has processed the
 > scan results).
 > 
 > When powerd has been told network_suspend_not_ok, it would not suspend
 > until told otherwise. (I'll probably ask you to implement this bit, I
 > guess you could do it rather quickly?)

sure.

as john suggested in another message, this is yet another
application-specific "protocol" being implemented in powerd, as
a heuristic to keep the user happy.  while i have no problem
adding it (what's one more? :-), we should certainly be tracking the
ongoing kernel work which might support all our suspend inhibitors in
a more cohesive way.


 > 
 > 
 > The above is the main functionality I want to implement. But, to kill
 > 2 birds in 1 stone, having this full-time daemon around lets me solve
 > another issue: rfkill.
 > 
 > You probably recall that sugar-0.84 executed "rfkill block olpc" when
 > the "disable wifi" checkbox was ticked. Unfortunately this was never

it used to be "rfkill block wifi", but perhaps that's changed.

 > upstreamed (boo), so 11.2.0 doesn't have that functionality. In
 > 11.2.0, the NM WirelessEnabled property is manipulated, and the
 > interface is brought down, but we don't actually cut power.
 > 
 > We do have the option of reimplementing it in Sugar, but (for now) I
 > think powerd would be a nicer place to do this. (Ultimately, we want
 > NM to do it).
 > 
 > So, in addition to the above, powerd-dbus would monitor for
 > NetworkManager's PropertiesChanged signal, and apply this simple
 > logic.
 > 
 >   if WirelessEnabled == true:
 >     rfkill unblock olpc
 >   else:
 >     rfkill block olpc

again, you're closer to the wireless bits than i am.  i guess we know that
NM won't be confused by having the card logically disappear when
it brings the interface down?  if so, then it sounds like a reasonable
plan.  (though it feels like a bit of a hack for it to be in powerd-dbus.)

paul

 > 
 > 
 > How does this sound to you?
 > 
 > Thanks,
 > Daniel

=---------------------
 paul fox, pgf at laptop.org