Set frame duration when injecting data packets?

[rodizio1]

Wanted to do some experiments with the frame duration field. Somehow, when injecting data frames (with 802.11g 18mbit rate), duration is always 48us. Have checked the injected 802.11 header, it seems the duration field is set correctly though.

Suspecting that the firmware overwrites this field, checked the ath9k htc firmware and found a function in if_owl.c (_static a_uint32_t ath_pktduration).

Figured I'd just replace the "duration = ...." line with "duration = 8192" to change it. Now the duration shown in wireshark packet captures is 258ms (0x0801). Still shorter than the packet takes to be transmitted. Hmm.

Am I missing something here?

BTW: Is there also a way to influence the length field in the PLCP header?

[erikarn]

no, it looks like the ath9k_htc firmware is calculating the duration incorrectly.

Is this the duration going out with the /frame/, or the duration being announced in an RTS or CTS-to-self?

-a

On 22 January 2017 at 07:04, Rodizio notifications@github.com wrote:

Wanted to do some experiments with the frame duration field. Somehow, when injecting data frames (with 802.11g 18mbit rate), duration is always 48us. Have checked the injected 802.11 header, it seems the duration field is set correctly though.

Suspecting that the firmware overwrites this field, checked the ath9k htc firmware and found a function in if_owl.c (static a_uint32_t ath_pkt_duration).

Figured I'd just replace the "duration = ...." line with "duration = 8192" to change it. Now the duration shown in wireshark packet captures is 258ms (0x0801). Still shorter than the packet takes to be transmitted. Hmm.

Am I missing something here?

BTW: Is there also a way to influence the length field in the PLCP header?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/121, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7ew9S3gSZixta4V0ny1rf9akrzONks5rU2_8gaJpZM4LqZ_M .

[rodizio1]

Oh sorry, just to clarify, I'm injecting frames here, so no RTS or CTS or other management frames associated with the data frames. This is the duration inside the data frame.

Just did some more testing with a nice tool called "hexinject" (http://hexinject.sourceforge.net/) This sends out a CTS frame with a correctly set duration field (32.000us):

echo "00 00 0D 00 04 80 02 00 02 00 00 00 00 C4 00 00 7D 01 02 03 04 05 06" | ./hexinject -p -i wlan14

So the driver or firmware does not overwrite it in all cases? Or maybe there is something wrong with how I inject the data frames, I'll first try to build a data frame by hand and try it with hexinject.

[rodizio1]

Did some more testing. Seems like the firmware or something else overwrites it when injecting data frames. Probably not a bug, as data frames usually have a duration of zero anyway and injecting traffic is not a "normal" use-case?

Changed the tx program so that it injects cts frames instead of data frames and the duration is set accordingly in the outgoing packets.

Only drawback is now that the firmware seems to use 1Mbit datarate for management frames (?)

Could somebody maybe give me a hint how I can patch the firmware to use higher datarates for management frames?

EDIT: One more thing: I noticed there are quite alot of other wifi stations around who send duration values that look way too high like 10.000us or even 30.000us. Can maybe somebody give me a hint where the duration is checked in the firmware? Maybe it would be a good idea to limit this to something more sane like 5ms or so.

Oh, BTW: just as a general warning to others reading here: USE A SHIELDED ENVIRONMENT when doing tests with cts frames and duration values. 1Mbit frames travel quite far, other stations hundreds of meters away will stop transmitting when they hear those frames!

[olerem]

@rodizio1 , hi take a look here: https://github.com/qca/open-ath9k-htc-firmware/commit/6aca322ee0817b39da999d946224fa858ef551da#diff-d89a76e909ac97f43228c098ed8facb3R966

[rodizio1]

data and management frames datarates settable via userspace? Awesome, I'll try that out, thanks.