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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
