[BUG]Unable to decrypt packet on wifi6 WNIC

[zhouruixi]

I run wfb_rx on an openwrt router[Xiaomi Ax3600] to receive data. The router has both wifi5[Qualcomm Atheros QCA9887] and wifi6[Qualcomm Atheros IPQ8074] wireless network cards. I set them to the same channel and bandwidth. wfb_rx can decode data from the wifi5 wireless network card, but the data received from the wifi6 wireless network card cannot be decoded. Thanks!

[svpcom]

Try to capture with tcpdump (use -w capture.dump) from the both cards and upload it here. Maybe wifi6 card add some header

[zhouruixi]

Try to capture with tcpdump (use -w capture.dump) from the both cards and upload it here. Maybe wifi6 card add some header

https://1drv.ms/f/s!AtB5-c6zgutCgY53ifYeQcWX5YASLg?e=DZUdZL

[svpcom]

I've found the root of this problem - in case of wifi6 it add 8 bytes (some garbage or additional data ?) to the end of captured packet. If I'll not found a good way to detect what it is then I'll just add command line flag to ignore last 8 bytes of the packet

[svpcom]

@zhouruixi Do you have another wifi6 adapter to check is this some wifi6 feature or this card (or driver) has implementation bug?

[zhouruixi]

@zhouruixi Do you have another wifi6 adapter to check is this some wifi6 feature or this card (or driver) has implementation bug?

I use Ubuntu 24.04+Intel Ax211 for testing, and it works fine. I don't have other brands of wifi6 devices for more testing now. I have uploaded the data packets obtained on Ax211 to onedrive. Maybe it's the IPQ8074 driver problem or OpenWrt. I'm not a professional and don't have the ability to conduct in-depth analysis. I really want to use wfb_rx on the wifi6 openwrt router and hope you can give a solution. Thank you.

[svpcom]

@zhouruixi Thanks for your dumps. They help me a lot to find root of this bug.

Quick solution for IPQ8074 is patch rx.cpp:

@@ -242,7 +243,8 @@ void Receiver::loop_iter(void)
         /* discard the radiotap header part */
         pkt += iterator._max_length;
         pktlen -= iterator._max_length;
+        pktlen -= 8 ;

         //fprintf(stderr, "CAPTURE: mcs: %u, bw: %u\n", mcs_index, bandwidth);
         if (pktlen > (int)sizeof(ieee80211_header))
         {

but I've not found a good way to distinguish bad and good cards during run time. So for quick and dirty solution you can add condition into code if interface name equals to "bad card" then do pktlen -= 8 ;

[zhouruixi]

@zhouruixi Thanks for your dumps. They help me a lot to find root of this bug.

Quick solution for IPQ8074 is patch rx.cpp:

@@ -242,7 +243,8 @@ void Receiver::loop_iter(void)
         /* discard the radiotap header part */
         pkt += iterator._max_length;
         pktlen -= iterator._max_length;
+        pktlen -= 8 ;

         //fprintf(stderr, "CAPTURE: mcs: %u, bw: %u\n", mcs_index, bandwidth);
         if (pktlen > (int)sizeof(ieee80211_header))
         {

but I've not found a good way to distinguish bad and good cards during run time. So for quick and dirty solution you can add condition into code if interface name equals to "bad card" then do pktlen -= 8 ;

1. It works on IPQ8074, but fails on wifi5. Does pktlen affect wfb aggregator?
2. We need more testing (wifi6 devices from other manufacturers, different drivers, and even wifi7 devices), If enough devices have pktlen issues and no effective way to detect and identify, we need an additional command line flag.

[svpcom]

1. Yes, it will fail on wifi5 because it doesn't feed extra bytes like ath11k on this router does. Yes it affects all wfb_rx modes. To work on wifi5 + wifi6 you need to add some "if" which will do pktlen -= 8 ; in case of wifi6 and do nothing in case of wifi5

[zhouruixi]

I have purchased a MediaTek based wifi6 router for testing, we will know the results in a few days.

[zhouruixi]

Working well with MediaTek based(MT7915E) wifi6 router. So this is just a non-universal problem caused by the ath11k driver. I will close this issue. Thanks again @svpcom

[svpcom]

@zhouruixi Please open issue on ath11k and/or openwrt about this bug. It is a real bug and it can affect other protocols

[zhouruixi]

Someone has found the same problem here