mac80211: Comment the order of HT RX reorder handler vs. RX handlers (aec67952) · Commits · 戴 / test

We are currently processing block ack reordering as a separate task before all other RX handlers. In theory, this is wrong since this step should be done only after duplicate removal (see Figure 6-1 in IEEE 802.11n). However, moving this needs some work and the current situation is not too bad. Add a comment here so that this small detail does not get forgotten and who knows, maybe someone has some extra time to take a look at cleaning this up. Signed-off-by:

Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by:

John W. Linville <linville@tuxdriver.com>

net/mac80211/rx.c

+12 −0

Original line number	Diff line number	Diff line
		@@ -2551,6 +2551,18 @@ void __ieee80211_rx(struct ieee80211_hw hw, struct sk_buff skb,
		return;
		}

		/*
		* In theory, the block ack reordering should happen after duplicate
		* removal (ieee80211_rx_h_check(), which is an RX handler). As such,
		* the call to ieee80211_rx_reorder_ampdu() should really be moved to
		* happen as a new RX handler between ieee80211_rx_h_check and
		* ieee80211_rx_h_decrypt. This cleanup may eventually happen, but for
		* the time being, the call can be here since RX reorder buf processing
		* will implicitly skip duplicates. We could, in theory at least,
		* process frames that ieee80211_rx_h_passive_scan would drop (e.g.,
		* frames from other than operational channel), but that should not
		* happen in normal networks.
		*/
		if (!ieee80211_rx_reorder_ampdu(local, skb, status))
		__ieee80211_rx_handle_packet(hw, skb, status, rate);

Admin message