[BUG]Unable to decrypt packet on ath11k drived wifi6 WNIC about wfb-ng HOT 15 CLOSED

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

from wfb-ng.

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

from wfb-ng.

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

from wfb-ng.

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

from wfb-ng.

@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.

from wfb-ng.

@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 ;

from wfb-ng.

@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.

from wfb-ng.

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

from wfb-ng.

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

from wfb-ng.

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

from wfb-ng.

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

from wfb-ng.

Someone has found the same problem here

from wfb-ng.

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

I've tried to trigger ath11k before with no luck :)
https://lists.infradead.org/pipermail/ath11k/2022-December/003764.html

from wfb-ng.

@legale It seems a bug in ath11k firmware (it is fullmac driver compared to ath9k which is softmac), so only Qualcomm can fix it :-(

from wfb-ng.

Hope a real solution...

from wfb-ng.