Repeating PREV_AUTH_NOT_VALID disconnects, *exactly* every 10 minutes. - hostapd and wpa_supplicant with linux bridging

[Jouni Malinen]

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