• Felix Fietkau's avatar
    wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces · 986e43b1
    Felix Fietkau authored
    The current mac80211 mesh A-MSDU receive path fails to parse A-MSDU packets
    on mesh interfaces, because it assumes that the Mesh Control field is always
    directly after the 802.11 header.
    802.11-2020 9.3.2.2.2 Figure 9-70 shows that the Mesh Control field is
    actually part of the A-MSDU subframe header.
    This makes more sense, since it allows packets for multiple different
    destinations to be included in the same A-MSDU, as long as RA and TID are
    still the same.
    Another issue is the fact that the A-MSDU subframe length field was apparently
    accidentally defined as little-endian in the standard.
    
    In order to fix this, the mesh forwarding path needs happen at a different
    point in the receive path.
    
    ieee80211_data_to_8023_exthdr is changed to ignore the mesh control field
    and leave it in after the ethernet header. This also affects the source/dest
    MAC address fields, which now in the case of mesh point to the mesh SA/DA.
    
    ieee80211_amsdu_to_8023s is changed to deal with the endian difference and
    to add the Mesh Control length to the subframe length, since it's not covered
    by the MSDU length field.
    
    With these changes, the mac80211 will get the same packet structure for
    converted regular data packets and unpacked A-MSDU subframes.
    
    The mesh forwarding checks are now only performed after the A-MSDU decap.
    For locally received packets, the Mesh Control header is stripped away.
    For forwarded packets, a new 802.11 header gets added.
    Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20230213100855.34315-4-nbd@nbd.name
    [fix fortify build error]
    Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    986e43b1
11n_rxreorder.c 26.7 KB