śr., 12 cze 2024 o 08:59 Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> napisał(a): > > ś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. 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).
