Re: Receiving broadcast data frames in AP mode

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2026-02-17 at 15:56 +0100, Yannik Marchand wrote:

>  > I actually have a Switch 2 now, so I guess I could theoretically try
>  > out some of these things - though I don't have a lot of real WiFi
>  > hardware.
> 
> That's cool! I didn't know that you are interested in Nintendo games.

Hah, not all that much, my kids more :-P

> I am running most of my experiments with an ALFA AWUS036ACM currently, 
> because my old laptop had an Intel chip, which (as you mentioned) 
> filtered out too much. My new laptop has a MediaTek chip, which seems to 
> work mostly fine. So, whether you need "real WiFi hardware" probably 
> depends on what you currently have.

Yeah guess that depends on how much filtering there is in the (lower)
MAC.

>  > Have you heard of Ferris on Air?
> 
> I didn't know about FoA. Currently, I don't really have the time to port 
> my implementation to a different stack, but it might be interesting if 
> we run into more issues later on.

Sure, was just thinking that has pretty low-level access, so could be
easy, and having it interop with an esp32 might be interesting. Also,
they've said they might want to support the esp32 as a wifi NIC for
Linux.

>  > This is ... odd. Is there encryption? I can't imagine why they'd throw
>  > away non-broadcast packets.
> 
> Yes, all data frames are encrypted with CCMP with a key that is derived 
> from information in the action frame. The interesting part is that the 
> first few packets do arrive at the Nintendo Switch, which makes me 
> believe that my encryption algorithm is correct. After I found that 
> using the broadcast address solved the problem, I have not investigated 
> the issue any further.

Sounds odd. Maybe some PN issue? But I guess would need some more debug.

>  > That sounds pretty awkward!
>  >
>  > ...
>  >
>  > So there really is no good default mode to implement this in, and
>  > while we could add a "nintendo mode" to the kernel, it'd be unlikely
>  > that hardware/firmware implements it?
> 
> It was quite difficult indeed :)
> 
> The biggest issue has really been the filtering, namely:
> * Dropping broadcast action frames in station mode while being 
> associated with an AP.
> * Dropping broadcast data frames in AP mode.
> * Dropping association frames in IBSS mode.
> 
> The first issue seems to affect mostly Intel hardware, while the other 
> two issues affect all my hardware.

Right.

> Of course, it would be nice if this could be solved in the kernel, but 
> I'm personally not familiar enough to judge whether this is possible, or 
> whether it would require support from the hardware vendor.

The *kernel* would be doable, but a lot of this is likely even happening
in (lower) MAC firmware, depending on the device. Certainly for Intel
devices.

In some devices maybe broadcast data frames are seen in AP mode, and
then we could just not drop them in the kernel? Or introduce a Nintendo-
AP mode or something, but like I said, the bigger issue is FW support.
Though having such a mode would also allow drivers to advertise "this
works".

johannes