On 16/04/2023 16:45, Artem Makhutov wrote:
> Hello,
>
> I am not sure if it is ok to write to you directly but I could not find a place where to open a ticket about the rtl8xxxu driver.
>
> I am having issues with the RTL8188EU (LogiLink WL0151A) where I get truncated packets when sending large packets. It's easy to reproduce with ping:
>
> ping -s 1430 10.10.0.1
> PING 10.10.0.1 (10.10.0.1) 1430(1458) bytes of data.
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=5 ttl=64 time=19.9 ms
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=8 ttl=64 time=250 ms
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=9 ttl=64 time=5.59 ms
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=10 ttl=64 time=1.94 ms
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=11 ttl=64 time=3.40 ms
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=12 ttl=64 time=1.94 ms
> 1438 bytes from 10.10.0.1 <http://10.10.0.1>: icmp_seq=13 ttl=64 time=1.89 ms
> [...]
> 15 packets transmitted, 7 received, 53.3333% packet loss, time 14345ms
> rtt min/avg/max/mdev = 1.885/40.654/249.918/85.640 ms
>
> With tcpdump I see logs like this on the wireless interface. Some parts of the packets seem to be broken...
>
> 13:16:54.448318 IP 10.10.0.111 > 10.10.0.1 <http://10.10.0.1>: ICMP echo request, id 63056, seq 14, length 1438
> 13:16:54.450391 IP truncated-ip - 4 bytes missing! 10.10.0.1 > 10.10.0.111 <http://10.10.0.111>: ICMP echo reply, id 63056, seq 14, length 1438
>
> Can you assist me to fix this issue?
>
> Thanks, Artem
Hi!
Adding linux-wireless because that's the place to report bugs.
Also bugzilla.kernel.org, but that's more dead.
Unfortunately my TP-Link TL-WN725N is fine even with bigger packets:
PING 192.168.1.7 (192.168.1.7) 2300(2328) bytes of data.
[1681659077.535489] 2308 bytes from 192.168.1.7: icmp_seq=1 ttl=64 time=7.93 ms
[1681659078.536313] 2308 bytes from 192.168.1.7: icmp_seq=2 ttl=64 time=6.24 ms
...
--- 192.168.1.7 ping statistics ---
24 packets transmitted, 24 received, 0% packet loss, time 23033ms
rtt min/avg/max/mdev = 6.210/8.375/22.621/3.633 ms
(The router wouldn't reply to anything more than "-s 1472" but
another computer on the network did.)
What version of the kernel/driver are you running? On what kind
of computer?
Did you use any module parameters?
Do you know if the other computer is receiving correct packets
from your RTL8188EU?
What's the biggest packet size which still works correctly?
Did you test any other driver, like this one:
https://github.com/lwfinger/rtl8188eu/tree/v5.2.2.4
or this one:
https://github.com/aircrack-ng/rtl8188eus
?
If the other computer is receiving correct packets, try this untested
patch to see what rtl8xxxu is actually receiving:
diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index c158137..5bec979 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -6142,6 +6147,8 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
return RX_TYPE_ERROR;
}
+ pr_warn("urb_len %d\n", urb_len);
+
do {
rx_desc = (struct rtl8xxxu_rxdesc16 *)skb->data;
_rx_desc_le = (__le32 *)skb->data;
@@ -6164,6 +6171,11 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
pkt_offset = roundup(pkt_len + drvinfo_sz + desc_shift +
sizeof(struct rtl8xxxu_rxdesc16), 128);
+ pr_warn(" pkt_cnt %d pkt_len %d drvinfo_sz %d desc_shift %d\n", pkt_cnt, pkt_len, drvinfo_sz, desc_shift);
+
+ print_hex_dump(KERN_WARNING, " ", DUMP_PREFIX_OFFSET, 32, 4,
+ skb->data, skb->len, EFUSE_MAP_LEN, true);
+
/*
* Only clone the skb if there's enough data at the end to
* at least cover the rx descriptor
Hello,
Am So., 16. Apr. 2023 um 19:47 Uhr schrieb Bitterblue Smith
<[email protected]>:
>
> On 16/04/2023 16:45, Artem Makhutov wrote:
> > Hello,
> >
> > I am not sure if it is ok to write to you directly but I could not find a place where to open a ticket about the rtl8xxxu driver.
> >
> > I am having issues with the RTL8188EU (LogiLink WL0151A) where I get truncated packets when sending large packets. It's easy to reproduce with ping:
> > [...]
> Hi!
>
> Adding linux-wireless because that's the place to report bugs.
> Also bugzilla.kernel.org, but that's more dead.
>
> Unfortunately my TP-Link TL-WN725N is fine even with bigger packets:
> [...]
Yes, I also have wifi networks where I have no issues at all. It seems
to be only related to some wifi routers.
With a Huawei AX3 router I have no issues. But with an Asus RT-AX53U i
am getting corrupted data.
> What version of the kernel/driver are you running? On what kind
> of computer?
It is an embedded device with a STM32MP157C processor. It runs an
5.15.67 kernel from ST (https://github.com/STMicroelectronics/linux/)
I have backported the rtl8xxxu driver from
https://github.com/torvalds/linux/ to that kernel by cherry-pick all
the related commits.
> Did you use any module parameters?
No, I have not tried any parameters yet.
> Do you know if the other computer is receiving correct packets
> from your RTL8188EU?
I have no ssh access to the router (it runs the stock firmware from
Asus), but I can try to do some tests on another PC later.
But I assume that it receives correct data as I can see a reply in tcpdump.
> What's the biggest packet size which still works correctly?
I think the magic number for ping is 1429. With ping -s 1428 I have no issues.
> Did you test any other driver, like this one:
> https://github.com/lwfinger/rtl8188eu/tree/v5.2.2.4
Yes, I have tried this one. Here I had no issue with packet loss, but
I was losing the wifi connection from time to time and the
auto-reconnect also did not work.
> or this one:
> https://github.com/aircrack-ng/rtl8188eus
I have not tried this one yet.
But I have also tried https://github.com/ivanovborislav/rtl8188eu
Here after some hours or days the wifi completely hangs up, loses the
connection and does not see any wifi networks any more at all.
> If the other computer is receiving correct packets, try this untested
> patch to see what rtl8xxxu is actually receiving:
> [...]
I have applied the patch.
For a working ping with a packet size of 1428 I am getting:
urb_len 1562
pkt_cnt 136 pkt_len 1506 drvinfo_sz 32 desc_shift 0
[...]
For a broken ping with a packet size of 1430 I am getting the data below.
The strange thing is that the urb_len 1560 for a 1430 bytes ping is
smaller than a urb_len 1562 for a 1428 bytes large ping...
urb_len 1560
pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
00000000: 84c405e0 21f0d700 30880052 0000104f 00000000 13283a20
000d002f 0000fcc2 .......!R..0O....... :(./.......
00000020: 0000fcfa 3800c200 00000300 001e0f00 8400d100 00000000
00244288 561cf170 .......8.................B$.p..V
00000040: eb50c390 142783f6 83f6eb50 05201427 00530007 00002000
aaaa0000 00000003 ..P...'.P...'. ...S.. ..........
00000060: 00450008 1428b205 01400000 0a0ab438 0a0a0100 00006f00
be070a23 78050100 ..E...([email protected]..#......x
00000080: 1d15643e 09080003 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e >d............................ !
000000a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000000c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000000e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000100: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000120: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000140: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000160: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000180: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000001a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000001c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000001e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000200: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000220: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000240: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000260: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000280: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000002a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000002c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000002e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000300: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000320: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000340: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000360: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000380: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000003a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000003c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000003e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000400: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000420: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000440: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000460: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000480: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000004a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000004c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000004e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000500: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000520: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000540: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000560: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000580: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000005a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000005c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000005e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000600: 85848382 89888786 8d8c8b8a 91908f8e 95949392 330f81a8
Thanks, Artem
On 18/04/2023 14:53, Artem Makhutov wrote:
> Hello,
>
> Am So., 16. Apr. 2023 um 19:47 Uhr schrieb Bitterblue Smith
> <[email protected]>:
>>
>> On 16/04/2023 16:45, Artem Makhutov wrote:
>>> Hello,
>>>
>>> I am not sure if it is ok to write to you directly but I could not find a place where to open a ticket about the rtl8xxxu driver.
>>>
>>> I am having issues with the RTL8188EU (LogiLink WL0151A) where I get truncated packets when sending large packets. It's easy to reproduce with ping:
>>> [...]
>> Hi!
>>
>> Adding linux-wireless because that's the place to report bugs.
>> Also bugzilla.kernel.org, but that's more dead.
>>
>> Unfortunately my TP-Link TL-WN725N is fine even with bigger packets:
>> [...]
>
> Yes, I also have wifi networks where I have no issues at all. It seems
> to be only related to some wifi routers.
> With a Huawei AX3 router I have no issues. But with an Asus RT-AX53U i
> am getting corrupted data.
>
>> What version of the kernel/driver are you running? On what kind
>> of computer?
>
> It is an embedded device with a STM32MP157C processor. It runs an
> 5.15.67 kernel from ST (https://github.com/STMicroelectronics/linux/)
> I have backported the rtl8xxxu driver from
> https://github.com/torvalds/linux/ to that kernel by cherry-pick all
> the related commits.
>
>> Did you use any module parameters?
>
> No, I have not tried any parameters yet.
>
>> Do you know if the other computer is receiving correct packets
>> from your RTL8188EU?
>
> I have no ssh access to the router (it runs the stock firmware from
> Asus), but I can try to do some tests on another PC later.
> But I assume that it receives correct data as I can see a reply in tcpdump.
>
>> What's the biggest packet size which still works correctly?
>
> I think the magic number for ping is 1429. With ping -s 1428 I have no issues.
>
>> Did you test any other driver, like this one:
>> https://github.com/lwfinger/rtl8188eu/tree/v5.2.2.4
>
> Yes, I have tried this one. Here I had no issue with packet loss, but
> I was losing the wifi connection from time to time and the
> auto-reconnect also did not work.
>
>> or this one:
>> https://github.com/aircrack-ng/rtl8188eus
>
> I have not tried this one yet.
>
> But I have also tried https://github.com/ivanovborislav/rtl8188eu
>
> Here after some hours or days the wifi completely hangs up, loses the
> connection and does not see any wifi networks any more at all.
>
>> If the other computer is receiving correct packets, try this untested
>> patch to see what rtl8xxxu is actually receiving:
>> [...]
>
> I have applied the patch.
>
> For a working ping with a packet size of 1428 I am getting:
> urb_len 1562
> pkt_cnt 136 pkt_len 1506 drvinfo_sz 32 desc_shift 0
> [...]
>
> For a broken ping with a packet size of 1430 I am getting the data below.
> The strange thing is that the urb_len 1560 for a 1430 bytes ping is
> smaller than a urb_len 1562 for a 1428 bytes large ping...
>
> urb_len 1560
> pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
Can you also capture the wifi traffic using some device which is not
handled by rtl8xxxu? With airodump-ng, wireshark, etc. Then you can
compare the pkt_len with what the capture device sees.
It could also be useful to see what the v5.2.2.4 driver receives,
both with 1428 and with 1430:
diff --git a/rtl8188e_rxdesc.c b/rtl8188e_rxdesc.c
index e6b0f77..2c34a71 100644
--- a/rtl8188e_rxdesc.c
+++ b/rtl8188e_rxdesc.c
@@ -38,6 +38,8 @@ void rtl8188e_query_rx_desc_status(
pattrib->pkt_len = cpu_to_le16(le32_to_cpu(report.rxdw0) & 0x00003fff); /* (u16)prxreport->pktlen; */
pattrib->drvinfo_sz = (u8)((le32_to_cpu(report.rxdw0) >> 16) & 0xf) * 8;/* (u8)(prxreport->drvinfosize << 3); */
+ pr_warn("%s: pkt_len: %d\n", __func__, le16_to_cpu(pattrib->pkt_len));
+
pattrib->physt = (u8)((le32_to_cpu(report.rxdw0) >> 26) & 0x1); /* (u8)prxreport->physt; */
pattrib->bdecrypted = (le32_to_cpu(report.rxdw0) & BIT(27)) ? 0 : 1; /* (u8)(prxreport->swdec ? 0 : 1); */
Also, can you show the hex dump from a good ping?
Hello,
Am Di., 18. Apr. 2023 um 17:49 Uhr schrieb Bitterblue Smith
<[email protected]>:
> Can you also capture the wifi traffic using some device which is not
> handled by rtl8xxxu? With airodump-ng, wireshark, etc. Then you can
> compare the pkt_len with what the capture device sees.
This is not possible right now as I only have remote access to the device.
> It could also be useful to see what the v5.2.2.4 driver receives,
> both with 1428 and with 1430:
From the v5.2.2.4 I am getting:
ping -I wlan0 -s 1430 10.10.0.1
[ 1249.671282] rtl8188e_query_rx_desc_status: pkt_len: 1508
[ 1249.697409] rtl8188e_query_rx_desc_status: pkt_len: 456
[...]
[ 1250.210397] rtl8188e_query_rx_desc_status: pkt_len: 119
[ 1250.306412] rtl8188e_query_rx_desc_status: pkt_len: 456
[...]
[ 1250.660650] rtl8188e_query_rx_desc_status: pkt_len: 1508
[...]
[ 1251.438777] rtl8188e_query_rx_desc_status: pkt_len: 264
[ 1251.533917] rtl8188e_query_rx_desc_status: pkt_len: 456
[ 1251.636303] rtl8188e_query_rx_desc_status: pkt_len: 456
[ 1251.677177] rtl8188e_query_rx_desc_status: pkt_len: 1508
ping -I wlan0 -s 1428 10.10.0.1
[ 1335.845038] rtl8188e_query_rx_desc_status: pkt_len: 1506
> Also, can you show the hex dump from a good ping?
Yes, I will try to capture that, but it's not so easy. The logs file
is overwritten verry fast and it's hard to catch.
I have also tested the driver from https://github.com/aircrack-ng/rtl8188eus
The problem occurs here too, but much less frequently than in the
rtl8xxxu driver. The strange thing is that sometimes I have 99% of
broken packets with the rtl8xxxu driver, but sometimes only 1%...
With the aircrack-ng driver I had maybe about 2% of failures.
Thanks, Artem
Hi
> I have also tested the driver from https://github.com/aircrack-ng/rtl8188eus
>
> The problem occurs here too, but much less frequently than in the
> rtl8xxxu driver. The strange thing is that sometimes I have 99% of
> broken packets with the rtl8xxxu driver, but sometimes only 1%...
> With the aircrack-ng driver I had maybe about 2% of failures.
Now I was just able to get the issue using the v5.2.2.4 driver too,
but not so frequent:
tcpdump -ni wlan0
19:39:26.407253 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 1, length 1438
19:39:26.410520 IP truncated-ip - 4 bytes missing! 10.10.0.1 >
10.10.0.111: ICMP echo reply, id 34080, seq 1, length 1438
19:39:27.442835 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 2, length 1438
19:39:27.445703 IP truncated-ip - 4 bytes missing! 10.10.0.1 >
10.10.0.111: ICMP echo reply, id 34080, seq 2, length 1438
19:39:28.482846 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 3, length 1438
19:39:28.490406 IP truncated-ip - 4 bytes missing! 10.10.0.1 >
10.10.0.111: ICMP echo reply, id 34080, seq 3, length 1438
19:39:29.522723 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 4, length 1438
19:39:29.525468 IP 10.10.0.1 > 10.10.0.111: ICMP echo reply, id 34080,
seq 4, length 1438
19:39:30.524193 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 5, length 1438
19:39:30.527100 IP 10.10.0.1 > 10.10.0.111: ICMP echo reply, id 34080,
seq 5, length 1438
19:39:31.525775 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 6, length 1438
19:39:31.528707 IP 10.10.0.1 > 10.10.0.111: ICMP echo reply, id 34080,
seq 6, length 1438
19:39:32.527400 IP 10.10.0.111 > 10.10.0.1: ICMP echo request, id
34080, seq 7, length 1438
19:39:32.531262 IP 10.10.0.1 > 10.10.0.111: ICMP echo reply, id 34080,
seq 7, length 1438
Apr 19 19:39:26 kern.warn kernel: [ 3228.967023]
rtl8188e_query_rx_desc_status: pkt_len: 1504
Apr 19 19:39:27 kern.warn kernel: [ 3230.002515]
rtl8188e_query_rx_desc_status: pkt_len: 1504
Apr 19 19:39:28 kern.warn kernel: [ 3231.047199]
rtl8188e_query_rx_desc_status: pkt_len: 1504
Apr 19 19:39:29 kern.warn kernel: [ 3232.082274]
rtl8188e_query_rx_desc_status: pkt_len: 1508
Apr 19 19:39:30 kern.warn kernel: [ 3233.083901]
rtl8188e_query_rx_desc_status: pkt_len: 1508
Thanks, Artem
On 19/04/2023 20:52, Artem Makhutov wrote:
> Hi
>
>> I have also tested the driver from https://github.com/aircrack-ng/rtl8188eus
>>
>> The problem occurs here too, but much less frequently than in the
>> rtl8xxxu driver. The strange thing is that sometimes I have 99% of
>> broken packets with the rtl8xxxu driver, but sometimes only 1%...
>> With the aircrack-ng driver I had maybe about 2% of failures.
>
> Now I was just able to get the issue using the v5.2.2.4 driver too,
> but not so frequent:
>
Interesting. Can you try rtl8xxxu with the newer v28 firmware?
You can download it from here:
https://bugzilla.kernel.org/attachment.cgi?id=304160
Hi,
> Interesting. Can you try rtl8xxxu with the newer v28 firmware?
> You can download it from here:
> https://bugzilla.kernel.org/attachment.cgi?id=304160
I might got better using rtl8xxxu, but I am not sure.
ping -I wlan0 -s 1430 10.10.0.1
69 packets transmitted, 35 received, 49.2754% packet loss
Here are the packet dumps of a broken and a working packet using v28 firmware:
Broken:
urb_len 1560
pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
00000000: 84c405e0 21f0d700 30880012 0000104d 00000000 4a9c2c2e
000c002f 0000fcbb .......!...0M........,.J/.......
00000020: 0000fc06 3700c800 00000300 00200e00 8400d000 00000000
00244288 561cf170 .......7...... ..........B$.p..V
00000040: eb50c390 142783f6 83f6eb50 01201427 00130007 00002000
aaaa0000 00000003 ..P...'.P...'. ...... ..........
00000060: 00450008 515cb205 01400000 0a0a7704 0a0a0100 00006f00
f6137e0a 4cbf0c00 ..E...\[email protected]...~.....L
00000080: 91606440 09080008 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e @d`........................... !
000000a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000000c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000000e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000100: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000120: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000140: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000160: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000180: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000001a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000001c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000001e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000200: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000220: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000240: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000260: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000280: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000002a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000002c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000002e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000300: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000320: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000340: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000360: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000380: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000003a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000003c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000003e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000400: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000420: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000440: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000460: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000480: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000004a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000004c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000004e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000500: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000520: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000540: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000560: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000580: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000005a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000005c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000005e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000600: 85848382 89888786 8d8c8b8a 91908f8e 95949392 5bbb8367
....................g..[
Working:
urb_len 1564
pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
00000000: 84c405e4 21f01700 3088001f 00001004 00000000 4cd774a4
000c002f 0000fdbc .......!...0.........t.L/.......
00000020: 0000fc06 4200c400 00000300 00210c00 8400d000 00000000
00244288 561cf170 .......B......!..........B$.p..V
00000040: eb50c390 142783f6 83f6eb50 01f01427 00200007 00002000
aaaa0000 00000003 ..P...'.P...'..... .. ..........
00000060: 00450008 8a61b205 01400000 0a0a3dff 0a0a0100 00006f00
661d9b70 4ce50b00 ..E...a...@..=.......o..p..f...L
00000080: 04d36440 09080000 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e @d............................ !
000000a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000000c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000000e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000100: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000120: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000140: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000160: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000180: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000001a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000001c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000001e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000200: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000220: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000240: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000260: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000280: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000002a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000002c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000002e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000300: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000320: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000340: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000360: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000380: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000003a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000003c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000003e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000400: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000420: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000440: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000460: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000480: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000004a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000004c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000004e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000500: 85848382 89888786 8d8c8b8a 91908f8e 95949392 99989796
9d9c9b9a a1a09f9e ................................
00000520: a5a4a3a2 a9a8a7a6 adacabaa b1b0afae b5b4b3b2 b9b8b7b6
bdbcbbba c1c0bfbe ................................
00000540: c5c4c3c2 c9c8c7c6 cdcccbca d1d0cfce d5d4d3d2 d9d8d7d6
dddcdbda e1e0dfde ................................
00000560: e5e4e3e2 e9e8e7e6 edecebea f1f0efee f5f4f3f2 f9f8f7f6
fdfcfbfa 0100fffe ................................
00000580: 05040302 09080706 0d0c0b0a 11100f0e 15141312 19181716
1d1c1b1a 21201f1e .............................. !
000005a0: 25242322 29282726 2d2c2b2a 31302f2e 35343332 39383736
3d3c3b3a 41403f3e "#$%&'()*+,-./0123456789:;<=>?@A
000005c0: 45444342 49484746 4d4c4b4a 51504f4e 55545352 59585756
5d5c5b5a 61605f5e BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
000005e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000600: 85848382 89888786 8d8c8b8a 91908f8e 95949392 094523fb
5c8ab2b3 .....................#E....\
Hi,
I made some more experiments and compared the data from the usb_urb
and what tcpdump sees.
The byte order is different in the dumps.
The correct ip packet ends with "92939495" / "95949392". This data is
present in both usb_urbs, but gets cut away in the broken ip packet.
What is the data after "95949392" in the usb_urb? Is this some kind of
footer or checksum? The working packet has a footer of 8 bytes and the
broken only 4 bytes?!?
Working dump:
000005e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000600: 85848382 89888786 8d8c8b8a 91908f8e 95949392 e4818dc6
b6a7742b ........................+t..
Broken dump:
000005e0: 65646362 69686766 6d6c6b6a 71706f6e 75747372 79787776
7d7c7b7a 81807f7e bcdefghijklmnopqrstuvwxyz{|}~...
00000600: 85848382 89888786 8d8c8b8a 91908f8e 95949392 98ce2927
....................')..
tcpdump working:
0x0580: 56575859 5a5b5c5d 5e5f6061 62636465 VWXYZ[\]^_`abcde
0x0590: 66676869 6a6b6c6d 6e6f7071 72737475 fghijklmnopqrstu
0x05a0: 76777879 7a7b7c7d 7e7f8081 82838485 vwxyz{|}~.......
0x05b0: 86878889 8a8b8c8d 8e8f9091 92939495 ................
tcpdump broken:
0x05b0: 86878889 8a8b8c8d 8e8f9091 ............
Thanks, Artem
Hi,
I think that I have found the problem: It happens when rx_desc->rxht
== 1 - then the urb is 4 bytes shorter...
ping -I wlan0 -s 1430 10.10.0.1
PING 10.10.0.1 (10.10.0.1) from 10.10.0.111 wlan0: 1430(1458) bytes of data.
1438 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=4.15 ms
1438 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=3.75 ms
1438 bytes from 10.10.0.1: icmp_seq=5 ttl=64 time=10.7 ms
1438 bytes from 10.10.0.1: icmp_seq=6 ttl=64 time=3.51 ms
1438 bytes from 10.10.0.1: icmp_seq=7 ttl=64 time=3.87 ms
1438 bytes from 10.10.0.1: icmp_seq=8 ttl=64 time=15.1 ms
1438 bytes from 10.10.0.1: icmp_seq=9 ttl=64 time=4.07 ms
--- 10.10.0.1 ping statistics ---
60 packets transmitted, 7 received, 88.3333% packet loss, time 61093ms
rtt min/avg/max/mdev = 3.508/6.451/15.148/4.258 ms
[ 1169.872268] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1170.880400] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1171.918891] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1172.920275] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1173.928173] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1174.923142] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1175.925513] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1176.937914] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1177.928766] pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 4 rxht 0
[ 1178.930020] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1180.007753] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1181.038649] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1182.078398] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1183.121640] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1184.160263] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1185.198899] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1186.238398] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1187.278894] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1188.317408] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1189.358896] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1190.397363] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1191.437506] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1192.477508] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1193.525388] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1193.526503] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1194.557519] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1195.597382] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1196.637391] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1197.677132] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1198.717459] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1199.757154] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1200.798631] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1201.837757] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1201.838238] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1202.877144] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1203.917151] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1204.959267] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1205.999003] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1207.041389] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1208.077647] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1209.117016] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1210.157660] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1211.199025] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1212.243013] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1213.288022] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 12 rxht 1
[ 1214.318898] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1215.358262] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1216.407514] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 13 rxht 1
[ 1217.437255] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1218.481128] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1219.517389] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1220.557630] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1221.596888] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1222.647014] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1223.677259] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 16 rxht 1
[ 1224.716758] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 16 rxht 1
[ 1225.760018] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1226.803382] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
[ 1227.837137] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1228.877134] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1229.917130] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 14 rxht 1
[ 1230.957130] pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 15 rxht 1
On 20/04/2023 14:40, Artem Makhutov wrote:
> Hi,
>
> I think that I have found the problem: It happens when rx_desc->rxht
> == 1 - then the urb is 4 bytes shorter...
>
That's very interesting. So it has a problem with MCS rates
According to Johannes Berg, the 8 bytes at the end of the working ping
are the MIC, which mac80211 will strip. Of course mac80211 doesn't know
that rtl8xxxu sometimes receives 4 bytes fewer.
What kind of encryption does the network have? Is it possible to try
without any encryption?
Another thing to try is software crypto, using this tested patch and
the module parameter debug=0x8000:
diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index cbf39ff..779f781 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -6651,6 +6651,9 @@ static int rtl8xxxu_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
dev_dbg(dev, "%s: cmd %02x, cipher %08x, index %i\n",
__func__, cmd, key->cipher, key->keyidx);
+ if (rtl8xxxu_debug & 0x8000)
+ return -EOPNOTSUPP; // use software crypto
+
if (vif->type != NL80211_IFTYPE_STATION)
return -EOPNOTSUPP;
Hi,
Am Do., 20. Apr. 2023 um 17:33 Uhr schrieb Bitterblue Smith
<[email protected]>:
>
> On 20/04/2023 14:40, Artem Makhutov wrote:
> > Hi,
> >
> > I think that I have found the problem: It happens when rx_desc->rxht
> > == 1 - then the urb is 4 bytes shorter...
> >
>
> That's very interesting. So it has a problem with MCS rates
>
> According to Johannes Berg, the 8 bytes at the end of the working ping
> are the MIC, which mac80211 will strip. Of course mac80211 doesn't know
> that rtl8xxxu sometimes receives 4 bytes fewer.
The strange thing is that this issue does not appear with another
Logilink WL0151 connected to my home network... Here the MCS rates
work fine and I am always getting the full 8 bytes.
> What kind of encryption does the network have? Is it possible to try
> without any encryption?
It uses WPA1 + WPA2 right now. Before that we had WPA2 only and it was
exactly the same.
I also did a test without encryption before. As far as I remember I
was able to send larger packets, but the issue was still there.
I will redo the test without encryption to double check it.
> Another thing to try is software crypto, using this tested patch and
> the module parameter debug=0x8000:
Just tried it out. There was no change at all.
Any ideas?
On 20/04/2023 19:12, Artem Makhutov wrote:
> Hi,
>
> Am Do., 20. Apr. 2023 um 17:33 Uhr schrieb Bitterblue Smith
> <[email protected]>:
>>
>> On 20/04/2023 14:40, Artem Makhutov wrote:
>>> Hi,
>>>
>>> I think that I have found the problem: It happens when rx_desc->rxht
>>> == 1 - then the urb is 4 bytes shorter...
>>>
>>
>> That's very interesting. So it has a problem with MCS rates
>>
>> According to Johannes Berg, the 8 bytes at the end of the working ping
>> are the MIC, which mac80211 will strip. Of course mac80211 doesn't know
>> that rtl8xxxu sometimes receives 4 bytes fewer.
>
> The strange thing is that this issue does not appear with another
> Logilink WL0151 connected to my home network... Here the MCS rates
> work fine and I am always getting the full 8 bytes.
>
>> What kind of encryption does the network have? Is it possible to try
>> without any encryption?
>
> It uses WPA1 + WPA2 right now. Before that we had WPA2 only and it was
> exactly the same.
> I also did a test without encryption before. As far as I remember I
> was able to send larger packets, but the issue was still there.
> I will redo the test without encryption to double check it.
>
>> Another thing to try is software crypto, using this tested patch and
>> the module parameter debug=0x8000:
>
> Just tried it out. There was no change at all.
>
> Any ideas?
So it's probably not related to the encryption.
The v5.2.2.4 driver uses USB RX aggregation, unless you disabled it.
We can try to use it in rtl8xxxu too, with this patch and the
module parameter dma_aggregation=1:
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index d9fd7f79821b..169b66333fc3 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1963,6 +1963,7 @@ struct rtl8xxxu_fileops {
};
extern int rtl8xxxu_debug;
+extern bool rtl8xxxu_dma_aggregation;
extern const struct rtl8xxxu_reg8val rtl8xxxu_gen1_mac_init_table[];
extern const u32 rtl8xxxu_iqk_phy_iq_bb_reg[];
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c
index 6d0f975f891b..ddd94d73816d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c
@@ -540,14 +540,25 @@ static void rtl8188eu_config_channel(struct ieee80211_hw *hw)
static void rtl8188eu_init_aggregation(struct rtl8xxxu_priv *priv)
{
u8 agg_ctrl, usb_spec;
+ u8 rxagg_usb_size = 16;
+ u8 rxagg_usb_timeout = 6;
usb_spec = rtl8xxxu_read8(priv, REG_USB_SPECIAL_OPTION);
usb_spec &= ~USB_SPEC_USB_AGG_ENABLE;
+ if (rtl8xxxu_dma_aggregation)
+ usb_spec |= USB_SPEC_USB_AGG_ENABLE;
rtl8xxxu_write8(priv, REG_USB_SPECIAL_OPTION, usb_spec);
agg_ctrl = rtl8xxxu_read8(priv, REG_TRXDMA_CTRL);
agg_ctrl &= ~TRXDMA_CTRL_RXDMA_AGG_EN;
rtl8xxxu_write8(priv, REG_TRXDMA_CTRL, agg_ctrl);
+
+ if (rtl8xxxu_dma_aggregation) {
+ rtl8xxxu_write8(priv, REG_USB_AGG_THRESH, rxagg_usb_size);
+ rtl8xxxu_write8(priv, REG_USB_AGG_TIMEOUT, rxagg_usb_timeout);
+
+ priv->rx_buf_aggregation = 1;
+ }
}
static int rtl8188eu_parse_efuse(struct rtl8xxxu_priv *priv)
@@ -1877,6 +1888,8 @@ struct rtl8xxxu_fileops rtl8188eu_fops = {
.cck_rssi = rtl8188e_cck_rssi,
.led_classdev_brightness_set = rtl8188eu_led_brightness_set,
.writeN_block_size = 128,
+ .rx_agg_buf_size = 15360 - sizeof(struct rtl8xxxu_rxdesc16)
+ - sizeof(struct rtl8723au_phy_stats),
.rx_desc_size = sizeof(struct rtl8xxxu_rxdesc16),
.tx_desc_size = sizeof(struct rtl8xxxu_txdesc32),
.has_tx_report = 1,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 01285300b83b..9b7fe459cb78 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -36,7 +36,7 @@
int rtl8xxxu_debug;
static bool rtl8xxxu_ht40_2g;
-static bool rtl8xxxu_dma_aggregation;
+bool rtl8xxxu_dma_aggregation;
static int rtl8xxxu_dma_agg_timeout = -1;
static int rtl8xxxu_dma_agg_pages = -1;
@@ -6240,6 +6240,8 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
return RX_TYPE_ERROR;
}
+ // pr_warn("urb_len: %d\n", urb_len);
+
do {
rx_desc = (struct rtl8xxxu_rxdesc16 *)skb->data;
_rx_desc_le = (__le32 *)skb->data;
@@ -6259,8 +6261,21 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
drvinfo_sz = rx_desc->drvinfo_sz * 8;
desc_shift = rx_desc->shift;
+
+ if (rx_desc->rpt_sel == 1) {
+ pkt_len = 8;
+ drvinfo_sz = 0;
+ desc_shift = 0;
+ } else if (rx_desc->rpt_sel == 2) {
+ pkt_len = pkt_len & 0x3ff;
+ drvinfo_sz = 0;
+ desc_shift = 0;
+ }
+
pkt_offset = roundup(pkt_len + drvinfo_sz + desc_shift +
- sizeof(struct rtl8xxxu_rxdesc16), 128);
+ sizeof(struct rtl8xxxu_rxdesc16), 4);
+
+ // pr_warn(" pkt_len %d pkt_offset %d rpt_sel %d\n", pkt_len, pkt_offset, rx_desc->rpt_sel);
/*
* Only clone the skb if there's enough data at the end to
@@ -6275,16 +6290,16 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
skb_pull(skb, sizeof(struct rtl8xxxu_rxdesc16));
+ phy_stats = (struct rtl8723au_phy_stats *)skb->data;
+
+ skb_pull(skb, drvinfo_sz + desc_shift);
+
+ skb_trim(skb, pkt_len);
+
if (rx_desc->rpt_sel) {
skb_queue_tail(&priv->c2hcmd_queue, skb);
schedule_work(&priv->c2hcmd_work);
} else {
- phy_stats = (struct rtl8723au_phy_stats *)skb->data;
-
- skb_pull(skb, drvinfo_sz + desc_shift);
-
- skb_trim(skb, pkt_len);
-
if (rx_desc->phy_stats)
priv->fops->parse_phystats(
priv, rx_status, phy_stats,
Hi,
Am Do., 20. Apr. 2023 um 20:26 Uhr schrieb Bitterblue Smith
<[email protected]>:
> So it's probably not related to the encryption.
>
> The v5.2.2.4 driver uses USB RX aggregation, unless you disabled it.
> We can try to use it in rtl8xxxu too, with this patch and the
> module parameter dma_aggregation=1:
I have tried it out. No changes. I will check the v5.2.2.4 tomorrow
again. Maybe it does not use HT mode so often and that's the reason
why the problem is not occuring that often...
As a workaround: What about checking the IP length field. If the
received packet is smaller by 4 bytes than what it should be then just
add extra 4 bytes at the end? Or does the MIC at the end have any
influence on anything?
Hi,
I have purchased an Asus RT-AX53U (running Asus 3.0.0.4.382_45213
firmware). And I can reproduce the problem in my own network now.
Now I have tested a TP-Link TL-WN722N wifi module. The problem is the
same here too.
In my setup the rxht mode works with rxmcs 19 and rxmcs 17... all
other values seem not to work...
urb_len 1564 pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 19 rxht 1 paggr 1 faggr 1
urb_len 1560 pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 18 rxht 1 paggr 1 faggr 1
urb_len 1560 pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 18 rxht 1 paggr 1 faggr 1
urb_len 1560 pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 18 rxht 1 paggr 1 faggr 1
urb_len 1564 pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 17 rxht 1 paggr 1 faggr 1
urb_len 1564 pkt_cnt 136 pkt_len 1508 drvinfo_sz 32 desc_shift 0
rxmcs 17 rxht 1 paggr 1 faggr 1
urb_len 1560 pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 16 rxht 1 paggr 1 faggr 1
urb_len 1560 pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 16 rxht 1 paggr 1 faggr 1
urb_len 1560 pkt_cnt 136 pkt_len 1504 drvinfo_sz 32 desc_shift 0
rxmcs 16 rxht 1 paggr 1 faggr 1
On 22/04/2023 00:59, Artem Makhutov wrote:
> Hi,
>
> Am Do., 20. Apr. 2023 um 20:26 Uhr schrieb Bitterblue Smith
> <[email protected]>:
>> So it's probably not related to the encryption.
>>
>> The v5.2.2.4 driver uses USB RX aggregation, unless you disabled it.
>> We can try to use it in rtl8xxxu too, with this patch and the
>> module parameter dma_aggregation=1:
>
> I have tried it out. No changes. I will check the v5.2.2.4 tomorrow
> again. Maybe it does not use HT mode so often and that's the reason
> why the problem is not occuring that often...
>
That's fortunate because RX aggregation makes the download speed
a lot worse for some reason.
> As a workaround: What about checking the IP length field. If the
> received packet is smaller by 4 bytes than what it should be then just
> add extra 4 bytes at the end? Or does the MIC at the end have any
> influence on anything?
That should work, but it's ugly.
If the router lets you change the MTU, does it help to make it smaller?
Do you have the problem with the v5.13.3 driver? If it works (other
than completely dying after a while) we should see what it does
differently compared to the v5.2.2.4 driver.
I don't have other ideas.
Hi,
> > As a workaround: What about checking the IP length field. If the
> > received packet is smaller by 4 bytes than what it should be then just
> > add extra 4 bytes at the end? Or does the MIC at the end have any
> > influence on anything?
>
> That should work, but it's ugly.
I did it and it is working, and yes, it is ugly :)
> If the router lets you change the MTU, does it help to make it smaller?
No, this is a bad idea. It will bring a lot of other issues.
> Do you have the problem with the v5.13.3 driver? If it works (other
> than completely dying after a while) we should see what it does
> differently compared to the v5.2.2.4 driver.
The v5.13.3 does not have this problem.
I have tested 3 different approaches and also made some quick speed tests:
1: I changed the skb length according the IP header so the packet is complete
2: Disabled ht by sband->ht_cap.ht_supported = false;
3: Tested v5.13.3 driver
Speedtests with iperf:
IP header hack:
24.5 Mbits/sec
HT hack:
18.7 Mbits/sec
v5.13.3 driver:
54.6 Mbits/sec
The v5.13.3 driver has the highest speed and does not have the missing
bytes bug. So it does something different...
On 25/04/2023 12:04, Artem Makhutov wrote:
> Hi,
>
>>> As a workaround: What about checking the IP length field. If the
>>> received packet is smaller by 4 bytes than what it should be then just
>>> add extra 4 bytes at the end? Or does the MIC at the end have any
>>> influence on anything?
>>
>> That should work, but it's ugly.
>
> I did it and it is working, and yes, it is ugly :)
>
>> If the router lets you change the MTU, does it help to make it smaller?
>
> No, this is a bad idea. It will bring a lot of other issues.
>
>> Do you have the problem with the v5.13.3 driver? If it works (other
>> than completely dying after a while) we should see what it does
>> differently compared to the v5.2.2.4 driver.
>
> The v5.13.3 does not have this problem.
>
> I have tested 3 different approaches and also made some quick speed tests:
>
> 1: I changed the skb length according the IP header so the packet is complete
> 2: Disabled ht by sband->ht_cap.ht_supported = false;
> 3: Tested v5.13.3 driver
>
> Speedtests with iperf:
> IP header hack:
> 24.5 Mbits/sec
>
> HT hack:
> 18.7 Mbits/sec
>
> v5.13.3 driver:
> 54.6 Mbits/sec
>
> The v5.13.3 driver has the highest speed and does not have the missing
> bytes bug. So it does something different...
I had another idea. Does this help?
diff --git a/rtl8xxxu_core.c b/rtl8xxxu_core.c
index cbf39ff..91878cf 100644
--- a/rtl8xxxu_core.c
+++ b/rtl8xxxu_core.c
@@ -4202,6 +4202,8 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
val32 = RCR_ACCEPT_PHYS_MATCH | RCR_ACCEPT_MCAST | RCR_ACCEPT_BCAST |
RCR_ACCEPT_MGMT_FRAME | RCR_HTC_LOC_CTRL |
RCR_APPEND_PHYSTAT | RCR_APPEND_ICV | RCR_APPEND_MIC;
+ if (priv->rtl_chip == RTL8188E)
+ val32 &= ~RCR_APPEND_MIC;
rtl8xxxu_write32(priv, REG_RCR, val32);
if (fops->init_reg_rxfltmap) {
@@ -6197,6 +6199,8 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8xxxu_priv *priv, struct sk_buff *skb)
rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
+ if (priv->rtl_chip == RTL8188E)
+ rx_status->flag |= RX_FLAG_MIC_STRIPPED;
if (!rx_desc->swdec)
rx_status->flag |= RX_FLAG_DECRYPTED;
Hi,
> I had another idea. Does this help?
No, unfortunately not. The packet size is now different and the
difference is now 12 bytes instead of 4 like before:
[ 95.519092] urb_len 1544 pkt_cnt 136 pkt_len 1488 drvinfo_sz 32
desc_shift 0 rxmcs 13 rxht 1 paggr 1 faggr 1
[ 96.565095] urb_len 1544 pkt_cnt 136 pkt_len 1488 drvinfo_sz 32
desc_shift 0 rxmcs 12 rxht 1 paggr 1 faggr 1
[ 96.567223] urb_len 1556 pkt_cnt 136 pkt_len 1500 drvinfo_sz 32
desc_shift 0 rxmcs 4 rxht 0 paggr 0 faggr 0
[ 97.600101] urb_len 1556 pkt_cnt 136 pkt_len 1500 drvinfo_sz 32
desc_shift 0 rxmcs 4 rxht 0 paggr 0 faggr 0
[...]
[ 129.872096] urb_len 1556 pkt_cnt 136 pkt_len 1500 drvinfo_sz 32
desc_shift 0 rxmcs 4 rxht 0 paggr 0 faggr 0
[ 129.879972] urb_len 1556 pkt_cnt 136 pkt_len 1500 drvinfo_sz 32
desc_shift 0 rxmcs 4 rxht 0 paggr 0 faggr 0
[ 130.870341] urb_len 1544 pkt_cnt 136 pkt_len 1488 drvinfo_sz 32
desc_shift 0 rxmcs 12 rxht 1 paggr 1 faggr 1
[ 131.919967] urb_len 1544 pkt_cnt 136 pkt_len 1488 drvinfo_sz 32
desc_shift 0 rxmcs 12 rxht 1 paggr 1 faggr 1
This time I have much less packet loss as I can only see rxmcs 13 as
max in my logs. Mostly ht mode is not in use for some reasons:
256 packets transmitted, 235 received, 8.20312% packet loss, time 256218ms
Without the patch I was getting 88% packet loss...
And the curious is why were rxmcs 17 and rxmcs 19 working and the rest
not (in my previous tests)?
Hi,
did some more tests and it looks like that
if (priv->rtl_chip == RTL8188E)
val32 &= ~RCR_APPEND_PHYSTAT;
Did the job for me... I will do some more tests later.