diff options
author | Christian Lamparter <chunkeey@googlemail.com> | 2010-11-29 20:53:23 +0100 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2010-11-30 13:23:06 -0500 |
commit | 2c31333a8fde7e26936a9f5371d02ff12c490993 (patch) | |
tree | 75bb0fc716caa240e7afc0245da0b5089bd3e420 /net/can | |
parent | cf63495d0dbe435b475a44672f5dee150da6471b (diff) |
mac80211: ignore non-bcast mcast deauth/disassoc franes
This patch fixes an curious issue due to insufficient
rx frame filtering.
Saqeb Akhter reported frequent disconnects while streaming
videos over samba: <http://marc.info/?m=128600031109136>
> [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
> [...]
The reason is that the device generates frames with slightly
bogus SA/TA addresses.
e.g.:
[ 2314.402316] Ignore 9f:1f:31:f8:64:ff
[ 2314.402321] Ignore 9f:1f:31:f8:64:ff
[ 2352.453804] Ignore 0d:1f:31:f8:64:ff
[ 2352.453808] Ignore 0d:1f:31:f8:64:ff
^^ the group-address flag is set!
(the correct SA/TA would be: 00:1f:31:f8:64:ff)
Since the AP does not know from where the frames come, it
generates a DEAUTH response for the (invalid) mcast address.
This mcast deauth frame then passes through all filters and
tricks the stack into thinking that the AP brutally kicked
us!
This patch fixes the problem by simply ignoring
non-broadcast, group-addressed deauth/disassoc frames.
Cc: Jouni Malinen <j@w1.fi>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Saqeb Akhter <saqeb.akhter@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'net/can')
0 files changed, 0 insertions, 0 deletions