[Bug 299326] LinuxKPI 802.11: deferred RX looks up the sender too early, so a retransmitted auth creates a second node for the same station

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299326

            Bug ID: 299326
           Summary: LinuxKPI 802.11: deferred RX looks up the sender too
                    early, so a retransmitted auth creates a second node
                    for the same station
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: fbsdbugs@westryn.net

Created attachment 275616
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=275616&action=edit
rx lookup order patch

I'm working on AP mode for ath10k on top of LinuxKPI, and I kept seeing one
client end up with several nodes at once.  The worst case: a phone sent four
auth frames within 330 ms (the first auth responses were slow to go out, so it
retransmitted), and the AP finished with four separate net80211 nodes for that
one MAC address, each one logged as "station authenticated (open)".

The cause is the deferred RX path added in 759a996d610. 
linuxkpi_ieee80211_rx() works out which node a frame belongs to when the frame
arrives (ieee80211_find_rxnode(), line 8422 in main), but the frame isn't
handed to net80211 until later, when lhw->rxq_task gets to it
(lkpi_80211_lhw_rxq_rx_one(), line 7983).  The answer can change in between.

With the auth retransmissions it goes like this:

  1. All four auth frames arrive before the task has processed the first one.
  2. Each lookup happens at arrival time, when the station is still unknown, so
all four come back NULL.
  3. The task then inputs them one at a time, and each one, being "from
nobody", goes through ieee80211_input_mimo_all() to iv_bss, which authenticates
it as a new station and calls ieee80211_dup_bss().
  4. The second, third and fourth frames should have found the node the first
one created, but their lookup was already done.

Native drivers don't hit this, because they look up the node and input the
frame in the same call.

A deauth from a client that has just authenticated runs into the same thing:
it's looked up as "from nobody" and goes to iv_bss instead of the station's
node.

As far as I can tell this only matters for AP mode, which LinuxKPI doesn't
support in the tree yet.  In station mode almost everything comes from the BSS
node anyway.  I'm reporting it now because it's latent in the shared RX path
and will be a problem as soon as AP mode is added.  In my tree each extra node
also got its own firmware peer, and the duplicate peers eventually led to a
panic.

## Fix

The attached patch keeps the lookup at arrival time, since the rest of
linuxkpi_ieee80211_rx() uses it for statistics and radiotap.  But unless the
driver named the station itself (sta != NULL), it drops that reference before
queueing the frame.  lkpi_80211_lhw_rxq_rx_one() then looks the sender up again
just before input, so frames are matched to nodes in the order they are
processed.  When the driver does pass a sta, nothing changes.

One visible effect: a frame that arrives just before a station leaves, but is
processed after it has gone, now finds no node.  net80211 answers it with a
"not authenticated" deauth (reason 6) instead of passing it to the stale node.
I believe that's the correct behaviour, but it does mean a few more of those
deauths show up in the logs.

## Testing

I ran this with ath10k (QCA6174) in AP mode, with an iPhone toggling Wi-Fi to
provoke the retransmissions.  Three auths in 80 ms now end up on a single node,
and a later retransmission reused the existing node, where before it would have
created a new one.  That's on my working branch, which is CURRENT plus my
AP-mode changes, not on a plain main kernel.

The patch applies to main as of 7c75c96d176 both with and without the patch in
299325; the two touch different lines of the same function.

-- 
You are receiving this mail because:
You are the assignee for the bug.