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? Compare air packets in non-secure connection between what A and C plays AP mode. Finding their difference might help to address problem.
