Date: Wed, 20 May 2020 10:46:07 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: net@FreeBSD.org Subject: Fwd: iwm rfkill Message-ID: <3ce69b85-7bae-417e-9411-e4bbae4050dd@FreeBSD.org> In-Reply-To: <a5464aaa-b30a-a058-a9b8-3bb230496ca8@FreeBSD.org> References: <a5464aaa-b30a-a058-a9b8-3bb230496ca8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Just in case. -------- Forwarded Message -------- Subject: Re: iwm rfkill Date: Wed, 20 May 2020 10:40:39 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Adrian Chadd <adrian.chadd@gmail.com> CC: freebsd-wireless@freebsd.org <wireless@freebsd.org> On 20/05/2020 02:11, Adrian Chadd wrote: > On Tue, 19 May 2020 at 16:07, Andriy Gapon <avg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ce69b85-7bae-417e-9411-e4bbae4050dd>