Fwd: iwm rfkill

Andriy Gapon avg at FreeBSD.org
Wed May 20 07:46:11 UTC 2020


Just in case.


-------- Forwarded Message --------
Subject: Re: iwm rfkill
Date: Wed, 20 May 2020 10:40:39 +0300
From: Andriy Gapon <avg at FreeBSD.org>
To: Adrian Chadd <adrian.chadd at gmail.com>
CC: freebsd-wireless at freebsd.org <wireless at freebsd.org>

On 20/05/2020 02:11, Adrian Chadd wrote:
> On Tue, 19 May 2020 at 16:07, Andriy Gapon <avg at freebsd.org> wrote:
> 
> 
>>>
>>> Adrian, thank you very much for your suggestion.
>>> Being a complete noob in this area, this is my stab at it:
>>> https://reviews.freebsd.org/D24923
>>
>> Also, I see that there is some friction between how rfkill is handled at the
>> driver / kernel level and how it gets (or doesn't get) known to userland.
>> First, at least Intel wireless drivers use ieee80211_suspend_all /
>> ieee80211_resume_all KPI when handling rfkill.  Those calls end up clearing or
>> setting IFF_DRV_RUNNING while userland mostly checks for IFF_UP.  But that's not
>> an issue actually -- I think that it's userland code that needs fixing.  The
>> issue is that the IFF_DRV_RUNNING changes become known to userland only by
>> accident if at all.
> 
> Ha! Ok.
> 
>>
>> Specifically, if we consider wpa_supplicant, it listens for notifications coming
>> via PF_ROUTE socket such as RTM_IFINFO.  So, wpa_supplicant depends on (a) a
>> notification getting generated in the first place; (b) the notification
>> conveying correct information about an interface's state.
>> As far as I can tell, net80211 layer does not try to do either of the above.
>> E.g., in the case of ieee80211_stop_locked there is an RTM_IFINFO notification
>> because of a link status change, but that notification by the state change
>> that's performed before IFF_DRV_RUNNING is cleared.
>> In the case of ieee80211_start_locked the situation is even worse.
>>
>> I wonder if ieee80211 should explicitly use rt_ifmsg() to post right
>> notifications at right times.
>> FWIW, I already have a patch for that and it seems to work.
> 
> Yes. :-) Let's get that in too.

Thank you for the very quick feedback!
https://reviews.freebsd.org/D24925

-- 
Andriy Gapon


More information about the freebsd-net mailing list