rtw88 multicast failure in AP mode

rtw88 multicast failure in AP mode

[Marcin Ślusarz]

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

RE: rtw88 multicast failure in AP mode

[Ping-Ke Shih]

Marcin Ślusarz <marcin.slusarz@gmail.com> 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. 

Re: rtw88 multicast failure in AP mode

[Marcin Ślusarz]

wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
>
> Marcin Ślusarz <marcin.slusarz@gmail.com> 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.

RE: rtw88 multicast failure in AP mode

[Ping-Ke Shih]

Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> >
> > Marcin Ślusarz <marcin.slusarz@gmail.com> 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.

Re: rtw88 multicast failure in AP mode

[Marcin Ślusarz]

śr., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
>
> Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > >
> > > Marcin Ślusarz <marcin.slusarz@gmail.com> 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.

RE: rtw88 multicast failure in AP mode

[Ping-Ke Shih]

Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> śr., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> >
> > Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > > >
> > > > Marcin Ślusarz <marcin.slusarz@gmail.com> 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/5318640d6eb74301b1fbf6d9385ba69e@realtek.com/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9

Re: rtw88 multicast failure in AP mode

[Marcin Ślusarz]

śr., 12 cze 2024 o 08:08 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
>
> Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > śr., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > >
> > > Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > > > >
> > > > > Marcin Ślusarz <marcin.slusarz@gmail.com> 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/5318640d6eb74301b1fbf6d9385ba69e@realtek.com/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9

Ok, I'll try that.

Re: rtw88 multicast failure in AP mode

[Marcin Ślusarz]

śr., 12 cze 2024 o 08:59 Marcin Ślusarz <marcin.slusarz@gmail.com> napisał(a):
>
> śr., 12 cze 2024 o 08:08 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> >
> > Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > > śr., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > > >
> > > > Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > > > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > > > > >
> > > > > > Marcin Ślusarz <marcin.slusarz@gmail.com> 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/5318640d6eb74301b1fbf6d9385ba69e@realtek.com/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).

[PATCH] wifi: rtw88: usb: unbreak multicast

[Marcin Ślusarz]

High queue is not functioning, for some reason.
Broken by 076f786a0ae14a81f40314b96a2d815e264bc213

Signed-off-by: Marcin Ślusarz <mslusarz@renau.com>
Cc: Po-Hao Huang <phhuang@realtek.com>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Kalle Valo <kvalo@kernel.org>
---
 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

RE: [PATCH] wifi: rtw88: usb: unbreak multicast

[Ping-Ke Shih]

Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> 
> High queue is not functioning, for some reason.
> Broken by 076f786a0ae14a81f40314b96a2d815e264bc213

Pointing out 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM behavior")
would be clearer. Please also mentioned the chip you are using. 

> 
> Signed-off-by: Marcin Ślusarz <mslusarz@renau.com>
> Cc: Po-Hao Huang <phhuang@realtek.com>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> Cc: Kalle Valo <kvalo@kernel.org>
> ---
>  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;

I think broadcast/multicast packets should go via HIGH queue is correct, but
somehow registers aren't configured correctly. Bernie (you have CC'ed) will
help to check registers. 


>         else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK)
>                 qsel = skb->priority;
>         else
> --
> 2.25.1

Re: [PATCH] wifi: rtw88: usb: unbreak multicast

[Ping-Ke Shih]

" =?utf-8?q?Marcin_=C5=9Alusarz?= " <marcin.slusarz@gmail.com> wrote:

> High queue is not functioning, for some reason.
> Broken by 076f786a0ae14a81f40314b96a2d815e264bc213
> 
> Signed-off-by: Marcin Ślusarz <mslusarz@renau.com>
> Cc: Po-Hao Huang <phhuang@realtek.com>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> Cc: Kalle Valo <kvalo@kernel.org>

Smith sent a patch [1] that finds cause and fixes the multicast problem.
However, vendor driver has been changed the flow a littlt bit, we will make
an new patch for this problem.

So, set patchset state to Superseded

[1] https://lore.kernel.org/linux-wireless/9174a776-4771-4351-85fa-476e240d8ace@gmail.com/T/#mee2cb8afb09f4bee333ab041defe20525d77f59e