iwm rfkill
Adrian Chadd
adrian.chadd at gmail.com
Tue May 19 23:11:36 UTC 2020
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.
-a
>
>
> --
> Andriy Gapon
More information about the freebsd-wireless
mailing list