Hi,
Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
another chip from a different vendor.
If A is in AP mode and A and B use the rtw88 driver, pinging A from B
and C by local name doesn't work because name resolution fails: avahi
on B and C sends a multicast request to resolve A.local, A sees it and
responds, but neither B nor C sees the response.
In the same situation, but with A and B using the rtl8821cu driver
(from https://github.com/morrownr/8821cu-20210916.git), everything
works - B and C see A's response and can resolve A.local.
If C is in AP mode, resolving C from A and B also works.
This leads me to believe there's something wrong with rtw88 when
sending multicast packets in AP mode.
When it works:
AP:
13:42:01.393649 IP 10.21.12.9.45190 > 10.21.12.1.53: 1519+ SOA? local. (23)
13:42:01.394137 IP 10.21.12.1.53 > 10.21.12.9.45190: 1519 Refused 0/0/0 (23)
13:42:01.395767 IP 10.21.12.9.49431 > 10.21.12.1.53: 1519+ SOA? local. (23)
13:42:01.395968 IP 10.21.12.1.53 > 10.21.12.9.49431: 1519 Refused 0/0/0 (23)
13:42:01.498904 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:42:01.499612 IP 10.21.12.1.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0
(Cache flush) A 10.21.12.1 (62)
13:42:01.502771 IP 10.21.12.9 > 10.21.12.1: ICMP echo request, id 597,
seq 0, length 64
13:42:01.502870 IP 10.21.12.1 > 10.21.12.9: ICMP echo reply, id 597,
seq 0, length 64
13:42:02.502636 IP 10.21.12.9 > 10.21.12.1: ICMP echo request, id 597,
seq 1, length 64
13:42:02.502832 IP 10.21.12.1 > 10.21.12.9: ICMP echo reply, id 597,
seq 1, length 64
13:42:03.503137 IP 10.21.12.9 > 10.21.12.1: ICMP echo request, id 597,
seq 2, length 64
13:42:03.503332 IP 10.21.12.1 > 10.21.12.9: ICMP echo reply, id 597,
seq 2, length 64
station:
13:41:55.542970 IP 10.21.12.9.45190 > 10.21.12.1.53: 1519+ SOA? local. (23)
13:41:55.545556 IP 10.21.12.1.53 > 10.21.12.9.45190: 1519 Refused 0/0/0 (23)
13:41:55.545888 IP 10.21.12.9.49431 > 10.21.12.1.53: 1519+ SOA? local. (23)
13:41:55.547212 IP 10.21.12.1.53 > 10.21.12.9.49431: 1519 Refused 0/0/0 (23)
13:41:55.648755 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:41:55.651057 IP 10.21.12.1.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0
(Cache flush) A 10.21.12.1 (62)
13:41:55.652154 IP 10.21.12.9 > 10.21.12.1: ICMP echo request, id 597,
seq 0, length 64
13:41:55.654220 IP 10.21.12.1 > 10.21.12.9: ICMP echo reply, id 597,
seq 0, length 64
13:41:56.652499 IP 10.21.12.9 > 10.21.12.1: ICMP echo request, id 597,
seq 1, length 64
13:41:56.654529 IP 10.21.12.1 > 10.21.12.9: ICMP echo reply, id 597,
seq 1, length 64
13:41:57.652892 IP 10.21.12.9 > 10.21.12.1: ICMP echo request, id 597,
seq 2, length 64
13:41:57.654789 IP 10.21.12.1 > 10.21.12.9: ICMP echo reply, id 597,
seq 2, length 64
when it doesn't:
AP:
13:47:00.331053 IP 10.21.12.9.53078 > 10.21.12.1.53: 43258+ SOA? local. (23)
13:47:00.331459 IP 10.21.12.1.53 > 10.21.12.9.53078: 43258 Refused 0/0/0 (23)
13:47:00.334759 IP 10.21.12.9.37501 > 10.21.12.1.53: 43258+ SOA? local. (23)
13:47:00.334955 IP 10.21.12.1.53 > 10.21.12.9.37501: 43258 Refused 0/0/0 (23)
13:47:00.438593 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:47:00.438923 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:47:00.441040 IP 10.21.12.1.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0
(Cache flush) A 10.21.12.1 (62)
13:47:01.443349 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:47:01.443771 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:47:01.445513 IP 10.21.12.1.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0
(Cache flush) A 10.21.12.1 (62)
13:47:03.441963 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:47:03.442094 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:47:03.442747 IP 10.21.12.1.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0
(Cache flush) A 10.21.12.1 (62)
station:
13:46:54.483807 IP 10.21.12.9.53078 > 10.21.12.1.53: 43258+ SOA? local. (23)
13:46:54.486122 IP 10.21.12.1.53 > 10.21.12.9.53078: 43258 Refused 0/0/0 (23)
13:46:54.487262 IP 10.21.12.9.37501 > 10.21.12.1.53: 43258+ SOA? local. (23)
13:46:54.489352 IP 10.21.12.1.53 > 10.21.12.9.37501: 43258 Refused 0/0/0 (23)
13:46:54.590785 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:46:55.593347 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
13:46:57.594809 IP 10.21.12.9.5353 > 224.0.0.251.5353: 0 A (QM)? A.local. (52)
If all systems connect to an external AP, A and B use rtw88 or
rtl8821cu, pinging A from B and C by local name (hostname.local)
works, but this goes through normal DNS service, so it doesn't prove
anything. I did some experiments with iperf though.
If A and B are connected to an external AP this works:
A: iperf -s -B 224.0.0.55 -u
B: iperf -c 224.0.0.55 -u
B: iperf -s -B 224.0.0.55 -u
A: iperf -c 224.0.0.55 -u
if A is in AP mode and uses rtw88 OR rtl8821cu, iperf fails both in
server and client mode:
iperf -s -B 224.0.0.55 -u
multicast join failed: No such device
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 224.0.0.55
Joining multicast group 224.0.0.55
Receiving 1470 byte datagrams
UDP buffer size: 176 KByte (default)
------------------------------------------------------------
iperf -c 224.0.0.55 -u
connect failed: Network is unreachable
If A is in AP mode and uses rtl8821cu, iperf between B (rtl8821cu) and
C works in both directions.
If A is in AP mode and uses rtw88, iperf between B (rtw88) and C
doesn't work (in both directions, no errors, just no traffic is
registered on the other side).
This indicates that there's something wrong with both sending and
receiving multicast packets in rtw88 in AP mode.
Please help me resolve this issue.
Cheers,
Marcin
Marcin Ślusarz <[email protected]> wrote:
> Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> another chip from a different vendor.
>
> If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> and C by local name doesn't work because name resolution fails: avahi
> on B and C sends a multicast request to resolve A.local, A sees it and
> responds, but neither B nor C sees the response.
>
> In the same situation, but with A and B using the rtl8821cu driver
> (from https://github.com/morrownr/8821cu-20210916.git), everything
> works - B and C see A's response and can resolve A.local.
>
> If C is in AP mode, resolving C from A and B also works.
>
> This leads me to believe there's something wrong with rtw88 when
> sending multicast packets in AP mode.
Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
Have you tried non-secure connection? (To check if encryption properly.)
I think this can help to address problem.
wt., 11 cze 2024 o 04:32 Ping-Ke Shih <[email protected]> napisał(a):
>
> Marcin Ślusarz <[email protected]> wrote:
> > Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> > another chip from a different vendor.
> >
> > If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> > and C by local name doesn't work because name resolution fails: avahi
> > on B and C sends a multicast request to resolve A.local, A sees it and
> > responds, but neither B nor C sees the response.
> >
> > In the same situation, but with A and B using the rtl8821cu driver
> > (from https://github.com/morrownr/8821cu-20210916.git), everything
> > works - B and C see A's response and can resolve A.local.
> >
> > If C is in AP mode, resolving C from A and B also works.
> >
> > This leads me to believe there's something wrong with rtw88 when
> > sending multicast packets in AP mode.
>
> Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
Yes, I see packets in both directions on both C and A if C is in AP mode.
> Have you tried non-secure connection? (To check if encryption properly.)
Nothing changes - rtw88 in AP mode sends multicast packets, but other
devices don't see them.
Marcin Ślusarz <[email protected]> wrote:
> wt., 11 cze 2024 o 04:32 Ping-Ke Shih <[email protected]> napisał(a):
> >
> > Marcin Ślusarz <[email protected]> wrote:
> > > Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> > > another chip from a different vendor.
> > >
> > > If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> > > and C by local name doesn't work because name resolution fails: avahi
> > > on B and C sends a multicast request to resolve A.local, A sees it and
> > > responds, but neither B nor C sees the response.
> > >
> > > In the same situation, but with A and B using the rtl8821cu driver
> > > (from https://github.com/morrownr/8821cu-20210916.git), everything
> > > works - B and C see A's response and can resolve A.local.
> > >
> > > If C is in AP mode, resolving C from A and B also works.
> > >
> > > This leads me to believe there's something wrong with rtw88 when
> > > sending multicast packets in AP mode.
> >
> > Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
>
> Yes, I see packets in both directions on both C and A if C is in AP mode.
>
> > Have you tried non-secure connection? (To check if encryption properly.)
>
> Nothing changes - rtw88 in AP mode sends multicast packets, but other
> devices don't see them.
How can you assert other devices don't see them? Receivers don't ACK
multicast/broadcast packets, so have you added debug log in A or B?
Compare air packets in non-secure connection between what A and C plays AP mode.
Finding their difference might help to address problem.
śr., 12 cze 2024 o 03:30 Ping-Ke Shih <[email protected]> napisał(a):
>
> Marcin Ślusarz <[email protected]> wrote:
> > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <[email protected]> napisał(a):
> > >
> > > Marcin Ślusarz <[email protected]> wrote:
> > > > Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> > > > another chip from a different vendor.
> > > >
> > > > If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> > > > and C by local name doesn't work because name resolution fails: avahi
> > > > on B and C sends a multicast request to resolve A.local, A sees it and
> > > > responds, but neither B nor C sees the response.
> > > >
> > > > In the same situation, but with A and B using the rtl8821cu driver
> > > > (from https://github.com/morrownr/8821cu-20210916.git), everything
> > > > works - B and C see A's response and can resolve A.local.
> > > >
> > > > If C is in AP mode, resolving C from A and B also works.
> > > >
> > > > This leads me to believe there's something wrong with rtw88 when
> > > > sending multicast packets in AP mode.
> > >
> > > Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
> >
> > Yes, I see packets in both directions on both C and A if C is in AP mode.
> >
> > > Have you tried non-secure connection? (To check if encryption properly.)
> >
> > Nothing changes - rtw88 in AP mode sends multicast packets, but other
> > devices don't see them.
>
> How can you assert other devices don't see them? Receivers don't ACK
> multicast/broadcast packets, so have you added debug log in A or B?
Because I don't see them in tcpdump output.
> Compare air packets in non-secure connection between what A and C plays AP mode.
I'm not sure what "air packets" mean. I don't have a radio sniffing
tool to see what's
going on, and by the time packets are available in the driver, they were already
processed and filtered by hardware, so they can't be considered "air".
If you have a specific place in the driver where you want me to put
debugs, let me know.
Marcin Ślusarz <[email protected]> wrote:
> śr., 12 cze 2024 o 03:30 Ping-Ke Shih <[email protected]> napisał(a):
> >
> > Marcin Ślusarz <[email protected]> wrote:
> > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <[email protected]> napisał(a):
> > > >
> > > > Marcin Ślusarz <[email protected]> wrote:
> > > > > Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> > > > > another chip from a different vendor.
> > > > >
> > > > > If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> > > > > and C by local name doesn't work because name resolution fails: avahi
> > > > > on B and C sends a multicast request to resolve A.local, A sees it and
> > > > > responds, but neither B nor C sees the response.
> > > > >
> > > > > In the same situation, but with A and B using the rtl8821cu driver
> > > > > (from https://github.com/morrownr/8821cu-20210916.git), everything
> > > > > works - B and C see A's response and can resolve A.local.
> > > > >
> > > > > If C is in AP mode, resolving C from A and B also works.
> > > > >
> > > > > This leads me to believe there's something wrong with rtw88 when
> > > > > sending multicast packets in AP mode.
> > > >
> > > > Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
> > >
> > > Yes, I see packets in both directions on both C and A if C is in AP mode.
> > >
> > > > Have you tried non-secure connection? (To check if encryption properly.)
> > >
> > > Nothing changes - rtw88 in AP mode sends multicast packets, but other
> > > devices don't see them.
> >
> > How can you assert other devices don't see them? Receivers don't ACK
> > multicast/broadcast packets, so have you added debug log in A or B?
>
> Because I don't see them in tcpdump output.
Multicast packets from A (in AP mode) didn't present in tcpdump output of B, but
multicast packets from C (in AP mode) did present in tcpdump output of B?
>
> > Compare air packets in non-secure connection between what A and C plays AP mode.
>
> I'm not sure what "air packets" mean. I don't have a radio sniffing
> tool to see what's
> going on,
rtw88 can be a sniffer.
sudo iw dev wlan0 interface add mon0 type monitor
sudo ifconfig mon0 up
sudo wireshark // select mon0, and switch channel by GUI toolbar
> and by the time packets are available in the driver, they were already
> processed and filtered by hardware, so they can't be considered "air".
> If you have a specific place in the driver where you want me to put
> debugs, let me know.
I didn't have a specific place. Just want to know how you confirmed
"AP sent packets" and "STA received packets". It seems like you didn't
capture packets in the air. So please setup rtw88 to do that. By the way,
monitor mode of rtw88 has broken [1] somehow. Please use older kernel to
capture packets.
[1] https://lore.kernel.org/linux-wireless/[email protected]/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9
śr., 12 cze 2024 o 08:08 Ping-Ke Shih <[email protected]> napisał(a):
>
> Marcin Ślusarz <[email protected]> wrote:
> > śr., 12 cze 2024 o 03:30 Ping-Ke Shih <[email protected]> napisał(a):
> > >
> > > Marcin Ślusarz <[email protected]> wrote:
> > > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <[email protected]> napisał(a):
> > > > >
> > > > > Marcin Ślusarz <[email protected]> wrote:
> > > > > > Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> > > > > > another chip from a different vendor.
> > > > > >
> > > > > > If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> > > > > > and C by local name doesn't work because name resolution fails: avahi
> > > > > > on B and C sends a multicast request to resolve A.local, A sees it and
> > > > > > responds, but neither B nor C sees the response.
> > > > > >
> > > > > > In the same situation, but with A and B using the rtl8821cu driver
> > > > > > (from https://github.com/morrownr/8821cu-20210916.git), everything
> > > > > > works - B and C see A's response and can resolve A.local.
> > > > > >
> > > > > > If C is in AP mode, resolving C from A and B also works.
> > > > > >
> > > > > > This leads me to believe there's something wrong with rtw88 when
> > > > > > sending multicast packets in AP mode.
> > > > >
> > > > > Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
> > > >
> > > > Yes, I see packets in both directions on both C and A if C is in AP mode.
> > > >
> > > > > Have you tried non-secure connection? (To check if encryption properly.)
> > > >
> > > > Nothing changes - rtw88 in AP mode sends multicast packets, but other
> > > > devices don't see them.
> > >
> > > How can you assert other devices don't see them? Receivers don't ACK
> > > multicast/broadcast packets, so have you added debug log in A or B?
> >
> > Because I don't see them in tcpdump output.
>
> Multicast packets from A (in AP mode) didn't present in tcpdump output of B, but
> multicast packets from C (in AP mode) did present in tcpdump output of B?
Yes
> > > Compare air packets in non-secure connection between what A and C plays AP mode.
> >
> > I'm not sure what "air packets" mean. I don't have a radio sniffing
> > tool to see what's
> > going on,
>
> rtw88 can be a sniffer.
>
> sudo iw dev wlan0 interface add mon0 type monitor
> sudo ifconfig mon0 up
> sudo wireshark // select mon0, and switch channel by GUI toolbar
>
>
> > and by the time packets are available in the driver, they were already
> > processed and filtered by hardware, so they can't be considered "air".
> > If you have a specific place in the driver where you want me to put
> > debugs, let me know.
>
> I didn't have a specific place. Just want to know how you confirmed
> "AP sent packets" and "STA received packets". It seems like you didn't
> capture packets in the air. So please setup rtw88 to do that. By the way,
> monitor mode of rtw88 has broken [1] somehow. Please use older kernel to
> capture packets.
>
> [1] https://lore.kernel.org/linux-wireless/[email protected]/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9
Ok, I'll try that.
śr., 12 cze 2024 o 08:59 Marcin Ślusarz <[email protected]> napisał(a):
>
> śr., 12 cze 2024 o 08:08 Ping-Ke Shih <[email protected]> napisał(a):
> >
> > Marcin Ślusarz <[email protected]> wrote:
> > > śr., 12 cze 2024 o 03:30 Ping-Ke Shih <[email protected]> napisał(a):
> > > >
> > > > Marcin Ślusarz <[email protected]> wrote:
> > > > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <[email protected]> napisał(a):
> > > > > >
> > > > > > Marcin Ślusarz <[email protected]> wrote:
> > > > > > > Let's assume we have 3 systems: A and B use 8821CU chip, and C uses
> > > > > > > another chip from a different vendor.
> > > > > > >
> > > > > > > If A is in AP mode and A and B use the rtw88 driver, pinging A from B
> > > > > > > and C by local name doesn't work because name resolution fails: avahi
> > > > > > > on B and C sends a multicast request to resolve A.local, A sees it and
> > > > > > > responds, but neither B nor C sees the response.
> > > > > > >
> > > > > > > In the same situation, but with A and B using the rtl8821cu driver
> > > > > > > (from https://github.com/morrownr/8821cu-20210916.git), everything
> > > > > > > works - B and C see A's response and can resolve A.local.
> > > > > > >
> > > > > > > If C is in AP mode, resolving C from A and B also works.
> > > > > > >
> > > > > > > This leads me to believe there's something wrong with rtw88 when
> > > > > > > sending multicast packets in AP mode.
> > > > > >
> > > > > > Have you captured air packets sent by C (AP mode)? (To check if TX properly.)
> > > > >
> > > > > Yes, I see packets in both directions on both C and A if C is in AP mode.
> > > > >
> > > > > > Have you tried non-secure connection? (To check if encryption properly.)
> > > > >
> > > > > Nothing changes - rtw88 in AP mode sends multicast packets, but other
> > > > > devices don't see them.
> > > >
> > > > How can you assert other devices don't see them? Receivers don't ACK
> > > > multicast/broadcast packets, so have you added debug log in A or B?
> > >
> > > Because I don't see them in tcpdump output.
> >
> > Multicast packets from A (in AP mode) didn't present in tcpdump output of B, but
> > multicast packets from C (in AP mode) did present in tcpdump output of B?
>
> Yes
>
> > > > Compare air packets in non-secure connection between what A and C plays AP mode.
> > >
> > > I'm not sure what "air packets" mean. I don't have a radio sniffing
> > > tool to see what's
> > > going on,
> >
> > rtw88 can be a sniffer.
> >
> > sudo iw dev wlan0 interface add mon0 type monitor
> > sudo ifconfig mon0 up
> > sudo wireshark // select mon0, and switch channel by GUI toolbar
> >
> >
> > > and by the time packets are available in the driver, they were already
> > > processed and filtered by hardware, so they can't be considered "air".
> > > If you have a specific place in the driver where you want me to put
> > > debugs, let me know.
> >
> > I didn't have a specific place. Just want to know how you confirmed
> > "AP sent packets" and "STA received packets". It seems like you didn't
> > capture packets in the air. So please setup rtw88 to do that. By the way,
> > monitor mode of rtw88 has broken [1] somehow. Please use older kernel to
> > capture packets.
> >
> > [1] https://lore.kernel.org/linux-wireless/[email protected]/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9
>
> Ok, I'll try that.
I don't see any useful difference with that - for mon0, there's a lot
of spamming from other networks, but MDNS communication looks exactly
the same as with tcpdump on wlan0, both in the configurations where
communication works and where it doesn't.
One interesting observation - even ARP requests seem to be affected by
this bug - pinging A from C by IP doesn't work until A starts pinging
C (which advertises its IP address).
High queue is not functioning, for some reason.
Broken by 076f786a0ae14a81f40314b96a2d815e264bc213
Signed-off-by: Marcin Ślusarz <[email protected]>
Cc: Po-Hao Huang <[email protected]>
Cc: Ping-Ke Shih <[email protected]>
Cc: Kalle Valo <[email protected]>
---
drivers/net/wireless/realtek/rtw88/usb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
index c25fd4b193a7..aacc5a105b15 100644
--- a/drivers/net/wireless/realtek/rtw88/usb.c
+++ b/drivers/net/wireless/realtek/rtw88/usb.c
@@ -492,9 +492,6 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct sk_buff *skb)
if (unlikely(ieee80211_is_mgmt(fc) || ieee80211_is_ctl(fc)))
qsel = TX_DESC_QSEL_MGMT;
- else if (is_broadcast_ether_addr(hdr->addr1) ||
- is_multicast_ether_addr(hdr->addr1))
- qsel = TX_DESC_QSEL_HIGH;
else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK)
qsel = skb->priority;
else
--
2.25.1