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

[Jouni Malinen]

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

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

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

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

-- 
Jouni Malinen                                            PGP id EFC895FA