Re: Kernel oops / WiFi connection failure with wpa_supplicant 2.7

[Denis Kenzior <denkenz@xxxxxxxxx>]

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 ;)

- 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...

- 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?

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

Regards,
-Denis