Received-SPF: pass (google.com: domain of linux-wireless+bounces-8831-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CA+GA0_t7RPsqQ2XztOtRyW3BVZfE54h+Rg+fxRNPL8qwQWKeDw@mail.gmail.com>
 <868343c920c24204972ddaa108e5d00e@realtek.com> <CA+GA0_vA1KRRyvnURfdjwVv5JBkRhkjdQnwrRWWKmZs9_z-X1w@mail.gmail.com>
 <c5b42d8b818b4bd5ac8a6921a29f9f18@realtek.com> <CA+GA0_vHeYLNw88KCnD9NACofA5rPJppj0nWZi+v5FqZLmpomA@mail.gmail.com>
 <9bec9d852273467fbf66af68e3c4d325@realtek.com>
In-Reply-To: <9bec9d852273467fbf66af68e3c4d325@realtek.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Wed, 12 Jun 2024 08:59:13 +0200
Message-ID: <CA+GA0_v0ee_VCRzwd-bA+XqMFZcMWs0oG0s_jFk6CjC0vV82ww@mail.gmail.com>
Subject: Re: rtw88 multicast failure in AP mode
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, Kalle Valo <kvalo@kernel.org>, 
	=?UTF-8?Q?Marcin_=C5=9Alusarz?= <mslusarz@renau.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C5=9Br., 12 cze 2024 o 08:08 Ping-Ke Shih <pkshih@realtek.com> napisa=C5=
=82(a):
>
> Marcin =C5=9Alusarz <marcin.slusarz@gmail.com> wrote:
> > =C5=9Br., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@realtek.com> napisa=
=C5=82(a):
> > >
> > > Marcin =C5=9Alusarz <marcin.slusarz@gmail.com> wrote:
> > > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisa=
=C5=82(a):
> > > > >
> > > > > Marcin =C5=9Alusarz <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 dri=
ver
> > > > > > (from https://github.com/morrownr/8821cu-20210916.git), everyth=
ing
> > > > > > 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 whe=
n
> > > > > > sending multicast packets in AP mode.
> > > > >
> > > > > Have you captured air packets sent by C (AP mode)? (To check if T=
X 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 pro=
perly.)
> > > >
> > > > Nothing changes - rtw88 in AP mode sends multicast packets, but oth=
er
> > > > 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 pla=
ys 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/5318640d6eb74301b1fbf6d9385ba6=
9e@realtek.com/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9

Ok, I'll try that.