Packet injection bugs for control frames

[cloudswei]

There are two issues when injecting control frames (RTS/CTS) to an ath9k-htc interface in monitor mode:

1. CTS packets are truncated and malformed
2. The unicast control frames are always re-transmitted unnecessarily to wait for an ACK

Reproduces:

Inject a CTS frame like below:

IEEE 802.11 Clear-to-send, Flags: ........C
Type/Subtype: Clear-to-send (0x001c)
Frame Control Field: 0xc400
.... ..00 = Version: 0
.... 01.. = Type: Control frame (1)
1100 .... = Subtype: 12
Flags: 0x00
.000 0000 1101 0001 = Duration: 209 microseconds
Receiver address: 00:11:22:33:44:55 (00:11:22:33:44:55)

The captured frame over-the-air becomes:

IEEE 802.11 Clear-to-send, Flags: .....R..C
Type/Subtype: Clear-to-send (0x001c)
Frame Control Field: 0xc408
.... ..00 = Version: 0
.... 01.. = Type: Control frame (1)
1100 .... = Subtype: 12
Flags: 0x08
.000 0000 1101 0001 = Duration: 209 microseconds
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]

The frame is malformed because the receiver address (00:11:22:33:44:55) is truncated to become 00:11:22:33, two ending bytes (44:55) are missing. And this CTS frame is re-transmitted by multiple times (R flag is set).

The reason is current ath9k_htc FW doesn't have TX handler for control frames, so all non-data frames are processed by management frame handler ath_tgt_send_mgt(). Function ath_tgt_send_mgt() expects all management frames to be in 3-address format and therefore the MAC header size should be 24 bytes (4-bye aligned), and unicast management frames need to be retransmitted when ACK is missing. Those assumptions are also applied to control frames, which results in truncating 2 bytes from CTS packet's receiver address and unnecessary retransmissions.

The fix is straightforward: remove the unnecessary alignment/truncation on MAC headers and apply NOACK flag to control frame's TX descriptor. After applying the patch below, the two issues can be fixed and the control-frame packet injection is working as expected.

diff --git a/target_firmware/wlan/if_owl.c b/target_firmware/wlan/if_owl.c
index 6dda78c..e522297 100755
--- a/target_firmware/wlan/if_owl.c
+++ b/target_firmware/wlan/if_owl.c
@@ -1108,7 +1108,7 @@ ath_tgt_send_mgt(struct ath_softc_tgt *sc,adf_nbuf_t hdr_buf, adf_nbuf_t skb,
        hdrlen = ieee80211_anyhdrsize(wh);
        pktlen = len;
        keyix = HAL_TXKEYIX_INVALID;
-       pktlen -= (hdrlen & 3);
+/*     pktlen -= (hdrlen & 3);*/
        pktlen += IEEE80211_CRC_LEN;
 
        if (iswep)
@@ -1142,6 +1142,8 @@ ath_tgt_send_mgt(struct ath_softc_tgt *sc,adf_nbuf_t hdr_buf, adf_nbuf_t skb,
                        atype = HAL_PKT_TYPE_NORMAL;
 
                break;
+       case IEEE80211_FC0_TYPE_CTL:
+               flags |= HAL_TXDESC_NOACK;
        default:
                atype = HAL_PKT_TYPE_NORMAL;
                break;

[erikarn]

hi! please file a pull request and I'll go review/test it out. Thanks!

…

-adrian

On Wed, 22 Jul 2020 at 18:40, cloudswei ***@***.***> wrote: There are two issues when injecting control frames (RTS/CTS) to an ath9k-htc interface in monitor mode: 1. CTS packets are truncated and malformed 2. The unicast control frames are always re-transmitted unnecessarily to wait for an ACK Reproduces: Inject a CTS frame like below: IEEE 802.11 Clear-to-send, Flags: ........C Type/Subtype: Clear-to-send (0x001c) Frame Control Field: 0xc400 .... ..00 = Version: 0 .... 01.. = Type: Control frame (1) 1100 .... = Subtype: 12 Flags: 0x00 .000 0000 1101 0001 = Duration: 209 microseconds Receiver address: 00:11:22:33:44:55 (00:11:22:33:44:55) The captured frame over-the-air becomes: IEEE 802.11 Clear-to-send, Flags: .....R..C Type/Subtype: Clear-to-send (0x001c) Frame Control Field: 0xc408 .... ..00 = Version: 0 .... 01.. = Type: Control frame (1) 1100 .... = Subtype: 12 Flags: 0x08 .000 0000 1101 0001 = Duration: 209 microseconds [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)] The frame is malformed because the receiver address (00:11:22:33:44:55) is truncated to become 00:11:22:33, two ending bytes (44:55) are missing. And this CTS frame is re-transmitted by multiple times (R flag is set). The reason is current ath9k_htc FW doesn't have TX handler for control frames, so all non-data frames are processed by management frame handler ath_tgt_send_mgt(). Function ath_tgt_send_mgt() expects all management frames to be in 2-address format and therefore the MAC header size should be 16 bytes (8-bye aligned), and unicast management frames need to be retransmitted when ACK is missing. Those assumptions are also applied to control frames, which results in truncating 2 bytes from CTS packet's receiver address and unnecessary retransmissions. The fix is straightforward: remove the unnecessary alignment/truncation on MAC headers and apply NOACK flag to control frame's TX descriptor: diff --git a/target_firmware/wlan/if_owl.c b/target_firmware/wlan/if_owl.c index 6dda78c..e522297 100755 --- a/target_firmware/wlan/if_owl.c +++ b/target_firmware/wlan/if_owl.c @@ -1108,7 +1108,7 @@ ath_tgt_send_mgt(struct ath_softc_tgt *sc,adf_nbuf_t hdr_buf, adf_nbuf_t skb, hdrlen = ieee80211_anyhdrsize(wh); pktlen = len; keyix = HAL_TXKEYIX_INVALID; - pktlen -= (hdrlen & 3); +/* pktlen -= (hdrlen & 3);*/ pktlen += IEEE80211_CRC_LEN; if (iswep) @@ -1142,6 +1142,8 @@ ath_tgt_send_mgt(struct ath_softc_tgt *sc,adf_nbuf_t hdr_buf, adf_nbuf_t skb, atype = HAL_PKT_TYPE_NORMAL; break; - case IEEE80211_FC0_TYPE_CTL: - flags |= HAL_TXDESC_NOACK; default: atype = HAL_PKT_TYPE_NORMAL; break; After applying the above patch, the two issues can be fixed and the control-frame packet injection is working as expected. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#162>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI2L3OFYUZQX5PR5VUU6ZLR46IHFANCNFSM4PFIMHQA> .

[erikarn]

hm, i'm not sure i get why the alignment thing isn't breaking on other mgmt traffic. shouldn't we be aligning the control frames that you're injecting via monitor mode?

[erikarn]

(the NOACK on control frames is good though!)

[cloudswei]

Since for a management frame, ieee80211_anyhdrsize() returns sizeof(struct ieee80211_frame), which is 2+2+6+6+6+2 = 24. So pktlen -= (hdrlen & 3) is equivalent to pktlen -= (24 & 3) or pktlen -= 0, actually doing nothing.

struct ieee80211_frame {
a_uint8_t i_fc[2];
a_uint8_t i_dur[2];
a_uint8_t i_addr1[IEEE80211_ADDR_LEN];
a_uint8_t i_addr2[IEEE80211_ADDR_LEN];
a_uint8_t i_addr3[IEEE80211_ADDR_LEN];
a_uint8_t i_seq[2];
/* possibly followed by addr4[IEEE80211_ADDR_LEN]; /
/ see below */
} adf_os_packed;

For monitor mode (maybe for normal operational mode also), we should not change anything on the frames passed from host.