All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: "Marcin Ślusarz" <marcin.slusarz@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"Kalle Valo" <kvalo@kernel.org>,
	"Marcin Ślusarz" <mslusarz@renau.com>
Subject: RE: rtw88 multicast failure in AP mode
Date: Wed, 12 Jun 2024 06:08:06 +0000	[thread overview]
Message-ID: <9bec9d852273467fbf66af68e3c4d325@realtek.com> (raw)
In-Reply-To: <CA+GA0_vHeYLNw88KCnD9NACofA5rPJppj0nWZi+v5FqZLmpomA@mail.gmail.com>

Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> śr., 12 cze 2024 o 03:30 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> >
> > Marcin Ślusarz <marcin.slusarz@gmail.com> wrote:
> > > wt., 11 cze 2024 o 04:32 Ping-Ke Shih <pkshih@realtek.com> napisał(a):
> > > >
> > > > Marcin Ślusarz <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 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?

> 
> > 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@realtek.com/T/#m6984dfc4a85b389511c253c2b97547a4148e83d9




  reply	other threads:[~2024-06-12  6:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 15:05 rtw88 multicast failure in AP mode Marcin Ślusarz
2024-06-11  2:32 ` Ping-Ke Shih
2024-06-11 11:10   ` Marcin Ślusarz
2024-06-12  1:30     ` Ping-Ke Shih
2024-06-12  5:55       ` Marcin Ślusarz
2024-06-12  6:08         ` Ping-Ke Shih [this message]
2024-06-12  6:59           ` Marcin Ślusarz
2024-06-12 15:24             ` Marcin Ślusarz
2024-06-14 10:28               ` [PATCH] wifi: rtw88: usb: unbreak multicast Marcin Ślusarz
2024-06-17  1:20                 ` Ping-Ke Shih
2024-07-30  7:40                 ` Ping-Ke Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9bec9d852273467fbf66af68e3c4d325@realtek.com \
    --to=pkshih@realtek.com \
    --cc=kvalo@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marcin.slusarz@gmail.com \
    --cc=mslusarz@renau.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.