Re: Kernel oops / WiFi connection failure with wpa_supplicant 2.7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/14/2019 10:18 PM, Denis Kenzior wrote:
Hi Arend,

On 01/14/2019 02:12 PM, Arend Van Spriel wrote:
On 1/8/2019 6:44 PM, Denis Kenzior wrote:
Hi Arend,

However, there is more to it. When these offloads were introduced, we discussed about having a PORT_AUTHORIZED event or not. It was decided passing an attribute in CONNECT and ROAMED event would suffice and that is what was implemented in brcmfmac. However, it seems time passed and the need for an explicit PORT_AUTHORIZED was there (probably Denis knows), which wpa_supplicant now supports thus ignoring the attribute in the CONNECT and ROAMED events. The brcmfmac driver was not changed accordingly. For this there are patches pending in linux-wireless which are necessary to have a working connection.


Coming in a bit late to this discussion, but it does raise a few points I wouldn't mind some clarification on:

- With commit 503c1fb98ba3, the kernel effectively changed the userspace API.  So I take it that breaking userspace APIs are OK sometimes? If so, I have lots of suggestions to make ;)

I bet you do :-p I think the rule of thumb is that there are no drivers providing the functionality behind the user-space API and/or no user-space applications are using that API.

Maybe this is a question for Johannes as well, but define 'user-space applications'?  If that includes wpa_s, wasn't the rule of thumb broken with that commit?

In my previous reply I wanted to add that it would be hard to proof that no user-space applications are using the API. Not sure exactly when things were added in wpa_s, but I suspect it was post-commit-503c1fb98ba3 so it did not have support for the user-space API before the commit.


- Is RTNL LINK_MODE / OPER_STATE status being (supposed to be?) affected by the driver during a roam?  E.g. if we're in a 802.1X network with userspace authentication, and driver roamed requiring a new 802.1X auth, then in theory the RTNL mode needs to be brought back out of UP state...

So do you expect the driver/cfg80211 to take care of that or the supplicant? I assumed wpa_supplicant would be doing that.


With regular roaming where we trigger a Deassociate/Deathenticate (either explicitly or implicitly) first, the interface goes into dormant mode by virtue of the carrier going down.

With this it isn't really clear whether the same is happening and who (kernel/userspace) should be doing what.  I would actually assume the kernel is/should be turning carrier off for the duration of the roam operation?

On what layer do we know 802.1X re-auth is required?

- The new API leaves a lot to be desired in terms of race conditions. For example, how long should userspace wait for EAPoL-EAP packets to arrive (before triggering its own EAPoL-Start for example) if a CMD_ROAMED event comes?

I think that question applies to CMD_CONNECT as well, right? Not sure if the specs provide any guidance for that. I can dive into that, but maybe someone like Jouni or Johannes know. If so, let me know ;-)

With CMD_CONNECT it is a bit more clear because you're most likely not specifying a PMKID for the first time, so you expect the authentication to happen in all cases.  If the AP doesn't respond after some small timeout, the supplicant can send its own EAPoL-Start.

With CMD_ROAMED it is less clear.


- What happens if userspace does send an EAPoL-Start in the middle of an offloaded 4-way handshake?

Probably those would be dropped.


I would love to have something more definitive than 'Probably', and it might be worth mentioning this hint in the documentation somewhere.

I was hesitant to use that word, but decided to do so simply because I can not speak for every driver and even for the brcmfmac driver that I maintain I will need to look into the firmware to be sure. I agree that a remark of that possibility is worth adding.

Regards,
Arend

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux