Received-SPF: pass (google.com: domain of linux-wireless+bounces-8828-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::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>
In-Reply-To: <c5b42d8b818b4bd5ac8a6921a29f9f18@realtek.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Wed, 12 Jun 2024 07:55:52 +0200
Message-ID: <CA+GA0_vHeYLNw88KCnD9NACofA5rPJppj0nWZi+v5FqZLmpomA@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 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: ava=
hi
> > > > 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 pr=
operly.)
> >
> > Yes, I see packets in both directions on both C and A if C is in AP mod=
e.
> >
> > > Have you tried non-secure connection? (To check if encryption properl=
y.)
> >
> > 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 A=
P 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 al=
ready
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.