xavi/android_kernel_m2note/net/mac80211/rx.c, branch ng-7.1.2

mac80211: ignore NullFunc frames in the duplicate detection

2019-05-03T17:26:16+00:00

commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream. NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 Change-Id: I524be05ea82cf34826ed826ac26e264968198a2c Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg [bwh: Backported to 3.16: The condition for "should we check for duplication" is in ieee80211_rx_h_check() and is not inverted] Signed-off-by: Ben Hutchings

mac80211: discard multicast and 4-addr A-MSDUs

2017-04-11T08:58:47+00:00

commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Signed-off-by: Johannes Berg Signed-off-by: Willy Tarreau

3.10.73 -> 3.10.74

2016-08-26T14:00:05+00:00

first commit

2016-08-15T02:19:42+00:00