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

[James Feeney]

On 11/19/2016 01:18 PM, Jouni Malinen wrote:
> On Wed, Nov 09, 2016 at 06:31:09PM -0700, James Feeney wrote:
>> wpa_supplicant v2.6
>> *not* using "-b br_ifname" old kernel bug work-around
>> *and* using "-b bridge0"
> 
> I'm not sure how to parse this.. So you do or do not have -b argument on
> the command line?

I am testing it both ways, with and without -b.  Trial and error...

>> I've set-up bridging over wireless and am seeing these "PREV_AUTH_NOT_VALID"
>> disconnects, *exactly*, on the second, every 10 minutes.  Since this is not at
>> all a random disconnect, I'm wondering, does someone knows why this is?
> 
> My first guess would be that you have the AP configured to do rekeying
> every 10 minutes and due to the kernel not providing the EAPOL-Key frame
> without the -b argument, station side is not replying to the rekeying
> messages (wpa_supplicant does not see them) and the AP ends up
> disconnecting the STA.

Yes, I eventually discovered that hostapd has a default "wpa_group_rekey=600".
It's a steep learning curve.

>> And then, including the "-b bridge0" option, these disconnects go away.  But, my
>> understanding was that this "-b" option was just a workaround for an old, and
>> presumably fixed, kernel bug.
> 
> What is that presumption based on? I'm not aware of any fix for the
> kernel regression having been accepted. If you disable the workaround in
> wpa_supplicant, I'm not at all surprised if there are combinations of
> bridging and/or bonding interfaces where EAPOL frame reception fails.

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.

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!

>> Without "-b bridge0", after enabling debugging in wpa_supplicant, each
>> PREV_AUTH_NOT_VALID is preceded by:
>>
>> wpa_supplicant[1527]: RTM_NEWLINK: ifi_index=3 ifname=wlp2s0 operstate=2
>> linkmode=1 master=5 ifi_family=0 ifi_flags=0x1803 ([UP])
>>
>> and then:
>>
>> kernel: wlp2s0: deauthenticated from 48:f8:b3:xx:xx:xx (Reason:
>> 2=PREV_AUTH_NOT_VALID)
>>
>> What I know about RTM_NEWLINK is limited to "man 7 rtnetlink".  If I understand,
>> in this RTM_NEWLINK message, wpa_supplicant is telling the kernel that there is
>> a new network interface - every 10 minutes - and this is wrong.
> 
> That is a kernel event message; not something from wpa_supplicant. In
> other words, the kernel tells that something in the interface state
> changes.

Thanks for that.  So, it happens in the kernel.  In another email I sent, which
didn't get copied to the list, I am thinking:

1)the Station MAC address is used in generating the Pairwise Transient Key, and
2)on a linux bridge interface, which chooses the lowest value MAC address from
the bridge participants, because of the STP, which it runs by default, the MAC
address on the bridge interface is most often different from the MAC address on
the wireless device interface, and 3)the hostapd Four Address mode will deliver
the four-way handshake Ethernet frames specifically to the bridge interface, as
the proper Distribution System Destination Address, therefore: wpa_supplicant
must be informed explicitly which interface will have the Distribution System
Destination Address, which is to say, the bridge interface MAC address.

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.

If that explanation seems correct, please add it to the documentation somewhere
- *prominently*.  It's a steep learning curve.

>> Where is this 600 second timer hiding?  Is this state-change coming from hostapd
>> on the Access Point?  Or from wpa_supplicant?  Or is there something going on
>> with the rtl8192ce driver?
> 
> Likely wpa_group_rekey parameter (default 600 seconds) in hostapd
> triggers this, but it sounds like the issue is on the station side where
> the kernel regression prevents wpa_supplicant from receiving EAPOL
> frames from an interface that is in a bridge and/or bonding interface.

So far, I have not encountered any problems connecting wireless through the
bonding interface.  Maybe the bonding module has been "fixed"?  Still, I have
not done any tests running a wired supplicant, or a "WPA2 Enterprise"
supplicant, though I don't know if that would be different.

Thanks for your comments!

James