On Mon, Nov 21, 2016 at 12:42:53PM -0700, James Feeney wrote: > Ah! Thanks for that. In retrospect, I just assumed it would have been fixed by > now. I still do not understand the kernel regression or the mechanism that > causes EAPOL frame reception to fail. If you have explained that somewhere, > please let me know. It has come up in some kernel discussions over the years.. This proposal to fix the issue and the following discussion might provide sufficient background information to understand the issue: https://patchwork.ozlabs.org/patch/282251/ > I had asked about this in September, and you had said "in practice, I'd > recommend testing the combination..." So I've been going at this with trial and > error. I have systemd unit files which automatically configure bridge and > bonding interfaces, and their enslaved interfaces, and it appears that > wpa_supplicant has to have the name of the bridge interface, even when it is > enslaved to a bonding interface. It just complicates the scripts, and I'd > prefer not designing by trial and error. > > There are other problems with the bridge module. It silently fails "iw dev > wlp2s0 set 4addr on" when the interface is a wireless interface! And I have > found *no* documentation for that, just an obscure comment on an Ubuntu forum, > of all places. I'm upset, because I spent quite a bit of time tracking that > down. And, the silent fail is pointless. While 4addr is required for wireless > bridging to work, I have to set 4addr regardless when the wpa_supplicant > interface is enslaved to a bonding interface and the bonding interface is > enslaved to the bridge interface. So instead of setting 4addr once, it has to > be set twice, by the unit file which creates the bridge interface - when the > wpa_supplicant interface is directly enslaved to the bridge interface, just to > bypass the silent fail - and again by the unit file starting wpa_supplicant - > for when wireless->bonding->bridge. > > And why fail silently, instead of just setting 4addr, if the developers feel > that way! While I might agree with most of this, the correct place to discuss the kernel interface would be on a Linux kernel mailing list (e.g., linux-wireless for 4addr and netdev from the bridge behavior). hostapd and wpa_supplicant will try to follow what the kernel requires.. Using bringing on the station side interface is unfortunately still very inconvenient and depends on non-standard hacks like 4addr design that does still require separate configuration on the client side. IEEE 802.11ak amendment may eventually help with this, but if you want to simplify the current setup, options would be either to get something changed on the kernel side (those other mailing lists) or somehow teach wpa_supplicant to set this parameter wherever it is needed (proposed patch on this mailing list would be a nice way of getting that done). > And, if wpa_supplicant does not get the EAPOL packet, it cannot respond to the > group rekeying event initiated by the AP. I'm guessing that the AP must then > send some kind of "rekey failed" packet - which is received by the kernel? Or > directly by wpa_supplicant? And the whole deauth/reconnect process repeats. The AP will disassociate the station if the station does not reply to EAPOL-Key rekeying messages and it is indeed this disconnection event that you showed here from kernel to wpa_supplicant.. So yes, this part is expected behavior if there is something wrong in EAPOL frame reception (which is the real issue here). > If that explanation seems correct, please add it to the documentation somewhere > - *prominently*. It's a steep learning curve. Feel free to propose text that you would think would clarify this and a good location for that. Bridging (or similar constructions needing different MAC addresses) on an IEEE 802.11 station are not exactly supported by the protocol today and that shows up here in complexity in hacks that are needed to get that functioning. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
