Re: iwm rfkill
On Tue, 19 May 2020 at 16:07, Andriy Gapon 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 ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: iwm rfkill
On 20/05/2020 01:40, Andriy Gapon wrote: > On 18/05/2020 18:42, Adrian Chadd wrote: >> On Mon, 18 May 2020 at 00:57, Andriy Gapon wrote: >>> >>> >>> I am trying to get my laptop fully functional and one of the things that >>> currently does not work as expected is a Wi-Fi / Radio special key. >>> It seems to be handled fully in hardware (but not 100% sure), but when I >>> press >>> it only bluetooth is turned off, but Wi-Fi stays on. >>> >>> This is the hardware: >>> iwm0: mem 0xfe80-0xfe801fff at >>> device >>> 0.0 on pci3 >>> iwm0: hw rev 0x220, fw ver 22.361476.0, address xx >>> >>> When I press the key I see these messages: >>> iwm0: iwm_intr: rfkill switch, disabling interface >>> ugen0.6: at usbus0 (disconnected) >>> ubt0: at uhub1, port 4, addr 5 (disconnected) >>> ubt0: detached >>> >>> However, ifconfig still shows that wlan0 is UP and RUNNING and the traffic >>> keeps >>> flowing. >>> >>> So, it seems that the RF KILL bit gets set and it's detected by the driver, >>> but >>> whatever the driver does is not enough to turn off the Wi-Fi. >>> Does anyone have any patches or suggestions or pointers (documentation, >>> etc) ? >> >> It should be pretty easy to hack in; look at what iwn does? It should >> just do a software thing to disable the interface in software. > > 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. 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. -- Andriy Gapon ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: iwm rfkill
On 18/05/2020 18:42, Adrian Chadd wrote: > On Mon, 18 May 2020 at 00:57, Andriy Gapon wrote: >> >> >> I am trying to get my laptop fully functional and one of the things that >> currently does not work as expected is a Wi-Fi / Radio special key. >> It seems to be handled fully in hardware (but not 100% sure), but when I >> press >> it only bluetooth is turned off, but Wi-Fi stays on. >> >> This is the hardware: >> iwm0: mem 0xfe80-0xfe801fff at >> device >> 0.0 on pci3 >> iwm0: hw rev 0x220, fw ver 22.361476.0, address xx >> >> When I press the key I see these messages: >> iwm0: iwm_intr: rfkill switch, disabling interface >> ugen0.6: at usbus0 (disconnected) >> ubt0: at uhub1, port 4, addr 5 (disconnected) >> ubt0: detached >> >> However, ifconfig still shows that wlan0 is UP and RUNNING and the traffic >> keeps >> flowing. >> >> So, it seems that the RF KILL bit gets set and it's detected by the driver, >> but >> whatever the driver does is not enough to turn off the Wi-Fi. >> Does anyone have any patches or suggestions or pointers (documentation, etc) >> ? > > It should be pretty easy to hack in; look at what iwn does? It should > just do a software thing to disable the interface in software. 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 -- Andriy Gapon ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
[Bug 246538] [Patch] Typo in ng_hci_le_connection_complete_ep struct
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246538 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: takawata Date: Tue May 19 13:58:53 UTC 2020 New revision: 361254 URL: https://svnweb.freebsd.org/changeset/base/361254 Log: Fix Typo in ng_hci_le_connection_complete_ep struct. PR: 246538 Submitted by: Marc Veldman Changes: head/sys/netgraph/bluetooth/include/ng_hci.h -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
[Bug 246505] [Patch] Add LE Whitelist commands to hccontrol
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246505 Takanori Watanabe changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #2 from Takanori Watanabe --- Committed. I wrote Wrong PR number by mistake -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
