kernel/net/mac80211/rx.c, branch linux-5.1.y

mac80211: drop robust management frames from unknown TA

2019-06-25T03:34:55Z

commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream. When receiving a robust management frame, drop it if we don't have rx->sta since then we don't have a security association and thus couldn't possibly validate the frame. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: un-schedule TXQs on powersave start

2019-03-29T10:14:11Z

Once a station enters powersave, its queues should not be returned by ieee80211_next_txq() anymore. They will be re-scheduled again after the station has woken up again Fixes: 1866760096bf4 ("mac80211: Add TXQ scheduling API") Signed-off-by: Felix Fietkau Acked-by: Toke Høiland-Jørgensen Signed-off-by: Johannes Berg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2019-02-24T20:06:19Z

Three conflicts, one of which, for marvell10g.c is non-trivial and requires some follow-up from Heiner or someone else. The issue is that Heiner converted the marvell10g driver over to use the generic c45 code as much as possible. However, in 'net' a bug fix appeared which makes sure that a new local mask (MDIO_AN_10GBT_CTRL_ADV_NBT_MASK) with value 0x01e0 is cleared. Signed-off-by: David S. Miller

mac80211: allocate tailroom for forwarded mesh packets

2019-02-22T13:00:40Z

Forwarded packets enter the tx path through ieee80211_add_pending_skb, which skips the ieee80211_skb_resize call. Fixes WARN_ON in ccmp_encrypt_skb and resulting packet loss. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg

mac80211: fix position of vendor_data read

2019-02-22T12:45:38Z

The ieee80211_vendor_radiotap was read from the beginning of the skb->data regardless of the existence of other elements in radiotap that would cause it to move to another position. Fix this by taking into account where it really should be. Signed-off-by: Liad Kaufman Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg

mac80211: Add attribute aligned(2) to struct 'action'

2019-01-25T09:17:25Z

During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO follow-MAC mode") a new struct 'action' was declared with packed attribute as: struct { struct ieee80211_hdr_3addr hdr; u8 category; u8 action_code; } __packed action; But since struct 'ieee80211_hdr_3addr' is declared with an aligned keyword as: struct ieee80211_hdr { __le16 frame_control; __le16 duration_id; u8 addr1[ETH_ALEN]; u8 addr2[ETH_ALEN]; u8 addr3[ETH_ALEN]; __le16 seq_ctrl; u8 addr4[ETH_ALEN]; } __packed __aligned(2); Solve the ambiguity of placing aligned structure in a packed one by adding the aligned(2) attribute to struct 'action'. This removes the following warning (W=1): net/mac80211/rx.c:234:2: warning: alignment 1 of 'struct ' is less than 2 [-Wpacked-not-aligned] Cc: Johannes Berg Suggested-by: Johannes Berg Signed-off-by: Mathieu Malaterre Signed-off-by: Johannes Berg

mac80211: fix miscounting of ttl-dropped frames

2019-01-19T08:11:44Z

In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl' counter when we decrement the ttl to zero. For unicast frames destined for other hosts, we stop processing the frame at that point. For multicast frames, we do not rebroadcast it in this case, but we do pass the frame up the stack to process it on this STA. That doesn't match the usual definition of "dropped," so don't count those as such. With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a peer in a ttl=1 network no longer increments the counter rapidly. Signed-off-by: Bob Copeland Signed-off-by: Johannes Berg

Merge tag 'mac80211-next-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2018-12-19T16:36:18Z

Johannes Berg says: ==================== This time we have too many changes to list, highlights: * virt_wifi - wireless control simulation on top of another network interface * hwsim configurability to test capabilities similar to real hardware * various mesh improvements * various radiotap vendor data fixes in mac80211 * finally the nl_set_extack_cookie_u64() we talked about previously, used for * peer measurement APIs, right now only with FTM (flight time measurement) for location * made nl80211 radio/interface announcements more complete * various new HE (802.11ax) things: updates, TWT support, ... ==================== Signed-off-by: David S. Miller

mac80211: Properly access radiotap vendor data

2018-12-19T08:41:10Z

The radiotap vendor data might be placed after some other radiotap elements, and thus when accessing it, need to access the correct offset in the skb data. Fix the code accordingly. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg

mac80211: fix radiotap vendor presence bitmap handling

2018-12-19T08:39:01Z

Due to the alignment handling, it actually matters where in the code we add the 4 bytes for the presence bitmap to the length; the first field is the timestamp with 8 byte alignment so we need to add the space for the extra vendor namespace presence bitmap *before* we do any alignment for the fields. Move the presence bitmap length accounting to the right place to fix the alignment for the data properly. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg