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.
Regards,
Ilan.
More information about the Hostap
mailing list