Regression on rfkill handling

Peer, Ilan ilan.peer
Sun Apr 27 03:03:10 PDT 2014

Hi Tomasz,

> I have noticed a regression recently on how wpa_supplicant handles rfkill
> status.
> Let's say 2 devices, one is hard "rfkillable" and the other one is not.
> In most cases: internal wifi card + a usb wifi dongle, for instance.
> Before the regression, wpa_supplicant was able to work so:
> - one device gets hard-rfkilled, the second is not
> - it can still manage to get the second one working properly
> The regression I have experienced is:
> - one device gets hard-rfkilled, the second is not
> - wpa_supplicant assumes all cards are hard-rfkilled thus does nothing with
> the second one
> git bisect ended up on that commit:
> 8c06db703d8cfd630a8eb738443a3d9134a3fc4a
> I would like a bit more explanation about that patch, which says:
> "On RF-kill, we should not request the kernel to start a P2P device."
> Well, afaik the kernel properly handles rfkill. So, to me, it's up to the kernel to
> handle that: you can ask to start the P2P device, it will do it or not depending
> on the rfkill status for that device. As it does for setting it up non-P2P device.
> Could you clarify the point of this patch then?

If I recall correctly, the patch tried to handle the case that rfkill unblock was not handled correctly for P2P_DEVICE interface, since the P2P Device was never put into WPA_INTERFACE_DISABLED state when wpa_driver_nl80211_finish_drv_init() was called and failed to start the P2P_DEVICE interface. Unfortunately, this fix missed the multi device support.

FWIW, I think that in addition to the patch you've sent, we can make the rfkill handling be device aware. I can work on a patch to implement this. 



More information about the Hostap mailing list