Re: Receiving broadcast data frames in AP mode

[Yannik Marchand <ymarchand@me.com>]

Hi Johannes,

 > Cool story. For some reason your emails never made it to the list it
 > seems? I'm replying privately because of that.

That was a mistake on my side. For the first email, I used "Reply" 
instead of "Reply All", and only realized that after the email had 
already been sent. For the second email, I accidentally sent it with 
HTML instead of plaintext (it might have been rejected for that reason).

 > 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.

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.

 > 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.

 > 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.

 > 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.

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.

(also, I'm leaving the previous emails quoted below in case a mailing 
list user wants to catch up)

Kind regards,
Yannik Marchand

On 17/02/2026 13:40, Johannes Berg wrote:
> Hi Yannick,
> 
> Cool story. For some reason your emails never made it to the list it
> seems? I'm replying privately because of that.
> 
> 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.
> 
> Have you heard of Ferris on Air? I've been in contact with one of the
> people involved in that, might be kind of interesting to interop with
> the switch from that ;-)
> 
> https://github.com/esp32-open-mac/FoA
> 
> 
> On Fri, 2026-02-13 at 17:30 +0100, Yannik Marchand wrote:
>> Update: I have no idea why, but sending all frames to ff:ff:ff:ff:ff:ff
>> instead of the MAC address of my Switch seems to have solved the issue.
>> It looks like all UDP packets are now being received properly :)
> 
> This is ... odd. Is there encryption? I can't imagine why they'd throw
> away non-broadcast packets.
> 
>> It seems that the protocol is somewhere between ad-hoc and
>> infrastructure mode. When a station joins the network, it must send an
>> authentication and association request to the host of the network,
>> which is similar to infrastructure mode. However, once authenticated,
>> the nodes can communicate directly with each other, which is more like
>> ad-hoc mode. Interestingly, packets from the host seem to have FromDS
>> set, while packets from other nodes in the network have neither FromDS
>> nor ToDS set.
> 
> IBSS (ad-hoc) can use authentication, but it's between each pair of
> devices, and not association I think, so it's indeed different. But I
> seem to remember from some (your?) documentation that the controller or
> host has some kind of beacon with the list of members, so I guess that
> makes some sense.
> 
>> Unfortunately, using an interface in IBSS mode did not work, because
>> none of my hardware supports receiving association requests in IBSS mode.
> 
> Curious that any hardware would even bother filtering. Though Intel FW
> does maybe filter, the folks working on those lower levels are a bit
> overdoing it sometimes ;-)
> 
>> Later, I learned about WiFi-Direct and P2P. While I initially thought
>> that using a P2P-GO mode interface would make it work, it seems that
>> it suffers from the same issue as AP mode, where broadcast data frames
>> are not received.
> 
> Yeah APs don't receive real broadcast data frames, so stands to reason
> they would drop those as useless.
> 
>> Then, I tried implementing the entire protocol in monitor mode. While
>> I have learned a lot, this turned out to be quite hard.
> 
> No surprise I guess.
> 
>> Today, I have finally managed to make it somewhat work. My setup uses
>> three interfaces, which is similar to what you suggested: one in AP
>> mode, one in monitor mode, and a TAP interface. The AP mode interface
>> handles the association and authentication frames. The monitor mode
>> interface handles the data frames. After parsing and decrypting the
>> data frames, the frames are written to the TAP interface, to avoid
>> having to implement L3 as well.
> 
> That sounds pretty awkward!
> 
> I guess your hardware then has some kind of extra "allow monitor"
> though, because it seems to receive more in the combination of AP +
> monitor than in pure AP. Intel hardware still wouldn't.
> 
> So overall this seems pretty awkward to implement over general purpose
> WiFi chips since you have conflicting requirements:
> 
>   - need beacon transmission and the timing
>     (normally IBSS, AP/P2P-GO, mesh)
>   - need auth/assoc handling
>     (normally AP/P2P-GO)
>   - need multicast data RX
>     (normally IBSS, client, maybe mesh)
> 
> 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?
> 
> johannes