In cfg80211_send_rx_auth function there was a warning if bssid of the received
authentication message was not found from the authtry_bsses table.
During the beginning of the authentication there is a small time window, when
handling of the received deauthentication message can cause information
for the access point to be removed from the authtry_bsses table before
authentication response is received. This triggers the warning. This has
been seen happening with several access points occasionally. At least
one of those (Asus) has been seen to send spurious deauthentication
messages after deauthentication. Possibly this warning could be triggered also
by forged deauthentication messages sent at a correct time.
Signed-off-by: Teemu Paasikivi <[email protected]>
---
net/wireless/mlme.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 0855f0d..2565882 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -23,7 +23,6 @@ void cfg80211_send_rx_auth(struct net_device *dev, const u8 *buf, size_t len)
u8 *bssid = mgmt->bssid;
int i;
u16 status = le16_to_cpu(mgmt->u.auth.status_code);
- bool done = false;
wdev_lock(wdev);
@@ -38,13 +37,10 @@ void cfg80211_send_rx_auth(struct net_device *dev, const u8 *buf, size_t len)
cfg80211_put_bss(&wdev->authtry_bsses[i]->pub);
}
wdev->authtry_bsses[i] = NULL;
- done = true;
break;
}
}
- WARN_ON(!done);
-
nl80211_send_rx_auth(rdev, dev, buf, len, GFP_KERNEL);
cfg80211_sme_rx_auth(dev, buf, len);
--
1.5.6.3
On Thu, 2010-05-27 at 11:27 +0200, ext Johannes Berg wrote:
> On Thu, 2010-05-27 at 11:48 +0300, Teemu Paasikivi wrote:
> > On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote:
> > > On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> > > > In cfg80211_send_rx_auth function there was a warning if bssid of the received
> > > > authentication message was not found from the authtry_bsses table.
> > > >
> > > > During the beginning of the authentication there is a small time window, when
> > > > handling of the received deauthentication message can cause information
> > > > for the access point to be removed from the authtry_bsses table before
> > > > authentication response is received. This triggers the warning. This has
> > > > been seen happening with several access points occasionally. At least
> > > > one of those (Asus) has been seen to send spurious deauthentication
> > > > messages after deauthentication. Possibly this warning could be triggered also
> > > > by forged deauthentication messages sent at a correct time.
> > >
> > > This doesn't seem right. Why is mac80211 not preventing those messages
> > > from bubbling up in that case?
> > >
> > > FWIW, this check is there for a reason -- we want to avoid telling
> > > userspace twice that we disconnected from a given AP, and we shouldn't
> > > be processing it anyway.
>
> > Normally, when the stack in the idle state, or connected to other access
> > point, those deauth messages doesn't cause a problem. The problem arises
> > if that spurious deauth message is received at the right moment, when
> > authentication to the access point has been started but response is not
> > yet received. If I'm correct in that the deauthentication message from
> > the AP during authentication is legal, this would be quite hard to
> > filter out.
>
> Yes .. I understand the scenario. You don't want to filter it out, you
> want to abort the authentication so you kill the work for it and never
> send the timeout to cfg80211.
>
> johannes
>
Isn't that already done? Aborting the authentication, I mean. The
warning is triggered by the authentication response in the
cfg80211_send_rx_auth function. Removal of the warning would keep logs
clean. I suppose that in the case where wdev->sme_state !=
CFG80211_SME_CONNECTING we could just bail out from the
cfg80211_send_rx_auth function instead of removing the warning.
Teemu
On Fri, 2010-05-28 at 09:55 +0300, Teemu Paasikivi wrote:
> > Yes .. I understand the scenario. You don't want to filter it out, you
> > want to abort the authentication so you kill the work for it and never
> > send the timeout to cfg80211.
> Isn't that already done? Aborting the authentication, I mean.
Evidently not? ieee80211_rx_mgmt_deauth() doesn't touch the work.
> The
> warning is triggered by the authentication response in the
> cfg80211_send_rx_auth function.
Right, ieee80211_rx_mgmt_deauth() removed the auth work, that frame
would never make it up to cfg80211.
> Removal of the warning would keep logs
> clean. I suppose that in the case where wdev->sme_state !=
> CFG80211_SME_CONNECTING we could just bail out from the
> cfg80211_send_rx_auth function instead of removing the warning.
No ... don't modify cfg80211.
johannes
On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote:
> On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> > In cfg80211_send_rx_auth function there was a warning if bssid of the received
> > authentication message was not found from the authtry_bsses table.
> >
> > During the beginning of the authentication there is a small time window, when
> > handling of the received deauthentication message can cause information
> > for the access point to be removed from the authtry_bsses table before
> > authentication response is received. This triggers the warning. This has
> > been seen happening with several access points occasionally. At least
> > one of those (Asus) has been seen to send spurious deauthentication
> > messages after deauthentication. Possibly this warning could be triggered also
> > by forged deauthentication messages sent at a correct time.
>
> This doesn't seem right. Why is mac80211 not preventing those messages
> from bubbling up in that case?
>
> FWIW, this check is there for a reason -- we want to avoid telling
> userspace twice that we disconnected from a given AP, and we shouldn't
> be processing it anyway.
>
> johannes
>
Normally, when the stack in the idle state, or connected to other access
point, those deauth messages doesn't cause a problem. The problem arises
if that spurious deauth message is received at the right moment, when
authentication to the access point has been started but response is not
yet received. If I'm correct in that the deauthentication message from
the AP during authentication is legal, this would be quite hard to
filter out.
Best regards,
Teemu
On Thu, 2010-05-27 at 11:48 +0300, Teemu Paasikivi wrote:
> On Wed, 2010-05-26 at 13:21 +0200, ext Johannes Berg wrote:
> > On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> > > In cfg80211_send_rx_auth function there was a warning if bssid of the received
> > > authentication message was not found from the authtry_bsses table.
> > >
> > > During the beginning of the authentication there is a small time window, when
> > > handling of the received deauthentication message can cause information
> > > for the access point to be removed from the authtry_bsses table before
> > > authentication response is received. This triggers the warning. This has
> > > been seen happening with several access points occasionally. At least
> > > one of those (Asus) has been seen to send spurious deauthentication
> > > messages after deauthentication. Possibly this warning could be triggered also
> > > by forged deauthentication messages sent at a correct time.
> >
> > This doesn't seem right. Why is mac80211 not preventing those messages
> > from bubbling up in that case?
> >
> > FWIW, this check is there for a reason -- we want to avoid telling
> > userspace twice that we disconnected from a given AP, and we shouldn't
> > be processing it anyway.
> Normally, when the stack in the idle state, or connected to other access
> point, those deauth messages doesn't cause a problem. The problem arises
> if that spurious deauth message is received at the right moment, when
> authentication to the access point has been started but response is not
> yet received. If I'm correct in that the deauthentication message from
> the AP during authentication is legal, this would be quite hard to
> filter out.
Yes .. I understand the scenario. You don't want to filter it out, you
want to abort the authentication so you kill the work for it and never
send the timeout to cfg80211.
johannes
On Wed, 2010-05-26 at 13:43 +0300, Teemu Paasikivi wrote:
> In cfg80211_send_rx_auth function there was a warning if bssid of the received
> authentication message was not found from the authtry_bsses table.
>
> During the beginning of the authentication there is a small time window, when
> handling of the received deauthentication message can cause information
> for the access point to be removed from the authtry_bsses table before
> authentication response is received. This triggers the warning. This has
> been seen happening with several access points occasionally. At least
> one of those (Asus) has been seen to send spurious deauthentication
> messages after deauthentication. Possibly this warning could be triggered also
> by forged deauthentication messages sent at a correct time.
This doesn't seem right. Why is mac80211 not preventing those messages
from bubbling up in that case?
FWIW, this check is there for a reason -- we want to avoid telling
userspace twice that we disconnected from a given AP, and we shouldn't
be processing it anyway.
johannes