Open rodizio1 opened 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
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..
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?
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?
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 ...
@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?
@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!
Tried with Kernel 4.14.71 and the 5.2.20 branch with AWUSH036ACH, exact same issue.
Tried the 5.3.4 branch now, this branch unfortunately also shows this packetloss issue.
@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.
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.
@rodizio1 I think the sequence number contains the the fragment number in the lower 4 bits.
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
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:
echo @start monitor mode; sudo iwconfig wlan0 mode monitor && sudo iwconfig wlan0 channel 13 && sudo ifconfig wlan0 up && /sbin/iwconfig
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.
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
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.
@AlexeyMavrin thank you, I'll give it another try on a RPI when I find a moment. Thank you!
pls consider closing the issue, when it's solved by now :)
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:
ifconfig for a Ralink rt5572 card:
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?