śr., 12 cze 2024 o 08:08 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a): > > Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote: > > śr., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a): > > > > > > Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote: > > > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@xxxxxxxxxxx> napisał(a): > > > > > > > > > > Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> 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@xxxxxxxxxxx/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9 Ok, I'll try that.
