search

aircrack-ng / rtl8812au

RTL8812AU/21AU and RTL8814AU driver with monitor mode and frame injection
GNU General Public License v2.0
3.47k stars 764 forks source link

Packetloss in monitor mode #116

Open rodizio1 opened 6 years ago

rodizio1 commented 6 years ago

I see packetloss somewhere about 2-8x as high in monitor mode compared to other cards. Could somebody give me a hint on how/where to debug this further?

The frames being injected on the other side are around 1024byte long 802.11g frames with 18 or 24mbit datarate, I've also tried 802.11b 11mbit, no difference. With two cards connected at the same time (so that both should receive approximately the same amount of packets) I get these results:

ifconfig for the Realtek rtl8814au card:

18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-7D-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:**657575** errors:0 dropped:1887 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifconfig for a Ralink rt5572 card:

24050f953373 Link encap:UNSPEC  HWaddr 24-05-0F-95-33-73-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:2304  Metric:1
          RX packets:**712355** errors:0 dropped:868 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:753741920 (718.8 MiB)  TX bytes:0 (0.0 B)

Another strange thing I've noticed, is that the last byte of the mac address in the ifconfig output seems to be constantly changing, have never seen any card doing that in monitor mode.

Is the card somehow in "scan mode" with that random mac address thingy that lately emerged?

root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-FD-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-9D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-9D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-0D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-CD-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-8D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-CD-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-4D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-BD-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-ED-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-8D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-DD-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-4D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-6D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-2D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-3D-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "HWaddr 18-D6"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-C8-ED-00-00-00-00-00-00-00-00
rodizio1 commented 6 years ago

Did a new test on 5Ghz to rule out external wifi interference.

After about 7 minutes, the two Ralink cards lost below 30 packets, while the Realtek card lost thousands:

root@wifibroadcast(rw):~# uptime
 18:09:21 up 7 min,  0 users,  load average: 0.52, 0.27, 0.12

root@wifibroadcast(rw):~# ifconfig 
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-41-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:486144 errors:0 dropped:9 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

24050f953373 Link encap:UNSPEC  HWaddr 24-05-0F-95-33-73-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:2304  Metric:1
          RX packets:493104 errors:0 dropped:4 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:514867291 (491.0 MiB)  TX bytes:0 (0.0 B)

24050f953521 Link encap:UNSPEC  HWaddr 24-05-0F-95-35-21-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:2304  Metric:1
          RX packets:493126 errors:0 dropped:14 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:514882348 (491.0 MiB)  TX bytes:0 (0.0 B)

root@wifibroadcast(rw):~# iwconfig 
18d6c7198154  IEEE 802.11  Mode:Monitor  Frequency:5.745 GHz  Tx-Power=18 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off

24050f953521  IEEE 802.11  Mode:Monitor  Frequency:5.745 GHz  Tx-Power=20 dBm   
          Retry short  long limit:2   RTS thr:off   Fragment thr:off
          Power Management:off

24050f953373  IEEE 802.11  Mode:Monitor  Frequency:5.745 GHz  Tx-Power=20 dBm   
          Retry short  long limit:2   RTS thr:off   Fragment thr:off
          Power Management:off
kimocoder commented 6 years ago

Yes, this isn't anything new, actually reported long way back. But what can we do about it? The drivers are a mix of old/new code and should REALLY have a new release instead of fixing all the issues with them.

If anyone wants to jump aboard, make a PR but for me it's not much left to do with it besides keeping kernel support up 2 date.

Realtek should have entered somewhere here, but..

rodizio1 commented 6 years ago

Do you have any more info on this issue or could point me to the other reports? I couldn't find anything.

I'm very keen on getting this (and other rtl8812/14) card to work, compared to the Ralink 5572 cards, the sensitivity on 5GHz seems tremendously better. I don't have measuring equipment, but it seems to be somewhere between 3 and 6db, when the Ralink card has ceased to receive anything, the 8814au is still receiving fine (well, apart from that packetloss problem).

I'm not really a kernel developer, so I'm afraid I can't fix this myself. What I can offer though is writing test-tools for making testing and indentifying issues easier.

What I would do now would be to try all kinds of different rtl8812au repos and branches to see if there is a version where this doesn't occur, maybe we can find the difference then?

Another idea would be adding a lot of printk's everywhere to get an idea where exactly the packets get lost on their way from the antennas to userspace. But I'm not sure where to start.

Do you know if that packetloss also occurs in managed/station mode?

rodizio1 commented 6 years ago

Well, this is totally strange:

When running "ifconfig 18d6c7198154", the mac address stays the same in the output:

root@wifibroadcast(rw):~# ifconfig 18d6c7198154 | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-00-00-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig 18d6c7198154 | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-00-00-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig 18d6c7198154 | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-00-00-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig 18d6c7198154 | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-00-00-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig 18d6c7198154 | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-00-00-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig 18d6c7198154 | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-00-00-00-00-00-00-00-00-00-00

When running just "ifconfig" (without explicit interface name parameter) the last byte changes:

root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-31-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-B1-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-F1-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-61-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-21-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-C1-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-51-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-F1-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-C1-00-00-00-00-00-00-00-00  
root@wifibroadcast(rw):~# ifconfig | grep "18d6c"
18d6c7198154 Link encap:UNSPEC  HWaddr 18-D6-C7-19-81-54-28-81-00-00-00-00-00-00-00-00

I was able to trace the incoming packets in the driver code up until the rtw_os_alloc_recvframe function in os_dep/linux/recv_linux.c so far by adding RTW_INFO("....");, lines in a lot of functions, but haven't been able yet to trace it further.

Does anyone maybe know where the packets are being handed to the driver?

rodizio1 commented 6 years ago

It seems the packets come in in the usb_read_port_complete() function, added debug messages there and I get:

usb_read_port_complete()-891: urb->actual_length:2189, MAX_RECVBUF_SZ:32768, RXDESC_SIZE:24

Seems, mostly two frames get delivered in one urb:

[   36.004439] RTW: usb_read_port_complete()-891: urb->actual_length:2189, MAX_RECVBUF_SZ:32768, RXDESC_SIZE:24
[   36.004445] RTW: skb_queue_len: 1
[   36.004456] RTW: usb_recv_tasklet in usb_ops_linux.c started (#else CONFIG_USE_BUFFER_ALLOC_RX
[   36.004461] RTW: function rtw_os_alloc_recvframe in recv_linux.c
[   36.004471] RTW: precvpriv->rx_pkts:257
[   36.004476] RTW: function rtw_os_alloc_recvframe in recv_linux.c
[   36.004483] RTW: precvpriv->rx_pkts:258

Now I somehow need to find a way to identify the frames to be able to see which ones are missing ...

atar-axis commented 6 years ago

@rodizio1 any news on that? my Alpha AWUS036ACH does have the same issue.

do the packages (which are lost) arrive at the driver or are they lost in the way?

kimocoder commented 6 years ago

@rodizio1 @atar-axis you should move up to the v5.2.20 branch which uses the v5.2.20.2 driver and check it for packetloss, please report the findings back here!

rodizio1 commented 5 years ago

Tried with Kernel 4.14.71 and the 5.2.20 branch with AWUSH036ACH, exact same issue.

rodizio1 commented 5 years ago

Tried the 5.3.4 branch now, this branch unfortunately also shows this packetloss issue.

rodizio1 commented 5 years ago

@kimocoder

I've also tested with an Alfa AWUS1900 now. Interestingly, there is no packetloss with that adapter. Although it also uses the 8814 chip, just like the TPLink Archer T9UH which shows the packetloss issue.

Do you see any way to debug this further? I'm not sure how to further narrow it down, like written some posts above, I was able to identify some code in the driver where the packets "pass by", but I'm not sure how to proceed.

rodizio1 commented 5 years ago

With the help from the info in this issue https://github.com/aircrack-ng/rtl8812au/issues/240 (thanks antifermion) I was able to make some small progress.

Can also see the frames in the recvbuf2recvframe() function now as well as printing pattrib->pkt_len.

Also found out, that the struct contains more interesting info, for example the seq_num (see inside rtw_recv.h, there's a struct rx_pkt_attrib).

However, I must be doing something wrong, packets with seqnumber "0xffff" always return 4095 when I print this out.

antifermion commented 5 years ago

@rodizio1 I think the sequence number contains the the fragment number in the lower 4 bits.

rodizio1 commented 5 years ago

Ah, thanks for the hint, that explains it.

The IEEE 802.11 standard [1] requires that the sequence number of each frame be assigned from a counter variable, which is incremented by one whenever a frame is sent out and whose value is modulo 4096.

65535 modulo 4096 = 4095

AlexeyMavrin commented 5 years ago

My problem seemed to be very similar - packet loss when receiving in the monitor mode. I struggled whole night yesterday and here is the workaround:

  1. Enable AP (access point) on the interface you are going to use for a monitor mode later on (make sure you see wifi network created successfully). (Note: that step could be a bit tedious see: AP setup)
  2. Disable the interface and put it to monitor mode: for wlan0: echo @start monitor mode; sudo iwconfig wlan0 mode monitor && sudo iwconfig wlan0 channel 13 && sudo ifconfig wlan0 up && /sbin/iwconfig
  3. Enjoy the link without much packet loss!

Not sure what is the actual problem solved by this workaround, suspecting some sort of power manegement (maybe card goes to power collapse/sleep time to time, and AP keeps it awake, even in monitor mode (this is just speculation!)). I was using this setup for wifibroadcast and tested the workaround with and without AP on three different RPI's - A+, 2 and 3. The difference is tremendous - pretty much no packet loss on an empty channel.

Just in case some testing specs: HW: tp-link TL-WN722N (I've got few of them, I think gen. 2 and 3, it's hard to tell from the label). Driver: rtl8188EUS_linux_v5.2.2.4_25483.20171222 Kernel RPI A+: 4.19.34+ Kernel RPI 2,3: 4.14.84-v7+

Hope that helps.

lennartkoopmann commented 5 years ago

I have the exact same problem and unfortunately @AlexeyMavrin's fix did not fix it for me. What I noticed is that only exactly 13% of received frames are not malformed. This is reproducible.

Tested with a AC1200 and a AWSUS1900

AlexeyMavrin commented 5 years ago

Hmm, the results were pretty conclusive to me. The RPI A+ was dropping periodically until installing AP on wlan0; I've also tested monitor mode on the same RPI but on the non-AP interface (wlan1), and it was dropping packets still. That makes it clear AP somehow fixed the problem (at least on my RPI setup). To doublecheck,

Though we still have not identified the problem, so it is very possible that the workaround would not run on every platform/setup. Just wanted to share what was working for me hopefully it could help someone else too.

lennartkoopmann commented 5 years ago

@AlexeyMavrin thank you, I'll give it another try on a RPI when I find a moment. Thank you!

cedricbambooza commented 3 years ago

pls consider closing the issue, when it's solved by now :)