Received-SPF: pass (google.com: domain of linux-wireless+bounces-8887-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> <CA+GA0_vHeYLNw88KCnD9NACofA5rPJppj0nWZi+v5FqZLmpomA@mail.gmail.com>
 <9bec9d852273467fbf66af68e3c4d325@realtek.com> <CA+GA0_v0ee_VCRzwd-bA+XqMFZcMWs0oG0s_jFk6CjC0vV82ww@mail.gmail.com>
In-Reply-To: <CA+GA0_v0ee_VCRzwd-bA+XqMFZcMWs0oG0s_jFk6CjC0vV82ww@mail.gmail.com>
From: =?UTF-8?Q?Marcin_=C5=9Alusarz?= <marcin.slusarz@gmail.com>
Date: Wed, 12 Jun 2024 17:24:54 +0200
Message-ID: <CA+GA0_vcUneM4Uo8fg0=4sCK049uhjv+NskotRbNg9Em0cnyUQ@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:59 Marcin =C5=9Alusarz <marcin.slusarz@gmail.com=
> napisa=C5=82(a):
>
> =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> napis=
a=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 fail=
s: avahi
> > > > > > > on B and C sends a multicast request to resolve A.local, A se=
es it and
> > > > > > > responds, but neither B nor C sees the response.
> > > > > > >
> > > > > > > In the same situation, but with A and B using the rtl8821cu d=
river
> > > > > > > (from https://github.com/morrownr/8821cu-20210916.git), every=
thing
> > > > > > > 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 w=
hen
> > > > > > > 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 p=
roperly.)
> > > > >
> > > > > Nothing changes - rtw88 in AP mode sends multicast packets, but o=
ther
> > > > > devices don't see them.
> > > >
> > > > How can you assert other devices don't see them? Receivers don't AC=
K
> > > > 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 p=
lays 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 alread=
y
> > > 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 wa=
y,
> > monitor mode of rtw88 has broken [1] somehow. Please use older kernel t=
o
> > capture packets.
> >
> > [1] https://lore.kernel.org/linux-wireless/5318640d6eb74301b1fbf6d9385b=
a69e@realtek.com/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).