Receiving broadcast data frames in AP mode

Receiving broadcast data frames in AP mode

[Yannik Marchand]

Hello,

I have been using nl80211 to implement local wireless communication with 
a Nintendo Switch device. The current implementation can be found here: 
https://github.com/kinnay/LDN.

We have run into the issue that we are not receiving any data frames in 
AP mode. In station mode it works fine. Inspecting the traffic with 
Wireshark in monitor mode showed that the data frames are being sent to 
the broadcast address ff:ff:ff:ff:ff:ff. Some research suggested that 
the Linux kernel might drop these packets by design: 
https://github.com/torvalds/linux/blob/7f7072574127c9e971cad83a0274e86f6275c0d5/net/mac80211/rx.c#L4443.

Currently, we are wondering if it is necessary to switch to adhoc mode. 
This would be inconvenient, as not all devices support adhoc mode, and I 
am also not sure how adhoc mode can be used correctly. We do need to 
send beacon frames, and process association requests, but 
NL80211_CMD_START_AP and NL80211_CMD_SET_BEACON seem to be unsupported 
in adhoc mode.

* Is it correct that there is no way to receive broadcast data frames in 
AP mode?
* Is there any documentation or example code on using adhoc mode with 
nl80211?
* Any general advice on moving forward?

Thanks,
Yannik Marchand

Re: Receiving broadcast data frames in AP mode

[Johannes Berg]

Hi,

> I have been using nl80211 to implement local wireless communication with 
> a Nintendo Switch device. The current implementation can be found here: 
> https://github.com/kinnay/LDN.

:)

> We have run into the issue that we are not receiving any data frames in 
> AP mode. In station mode it works fine. Inspecting the traffic with 
> Wireshark in monitor mode showed that the data frames are being sent to 
> the broadcast address ff:ff:ff:ff:ff:ff. Some research suggested that 
> the Linux kernel might drop these packets by design: 
> https://github.com/torvalds/linux/blob/7f7072574127c9e971cad83a0274e86f6275c0d5/net/mac80211/rx.c#L4443.

Yes, a real AP will never receive broadcast data frames, since it
controls the BSS and all traffic flows through it. In fact, hardware or
firmware would likely filter them as well, so even removing this check
may not address this for all devices.

> Currently, we are wondering if it is necessary to switch to adhoc mode. 

That might not be a bad idea, but then you don't have control over which
station is sending beacons - though I guess if you actually have
multiple Linux hosts it wouldn't matter so much?

> This would be inconvenient, as not all devices support adhoc mode,

Not all devices support AP mode either, and see above wrt. filtering, so
I think either way you don't have some devices.

>  and I 
> am also not sure how adhoc mode can be used correctly. We do need to 
> send beacon frames, and process association requests, but 
> NL80211_CMD_START_AP and NL80211_CMD_SET_BEACON seem to be unsupported 
> in adhoc mode.

I don't know what you need from the beacon - almost sounds like not much
- so might not need SET_BEACON rather than JOIN_IBSS. Managing stations
from userspace is supported for secure IBSS though, wpa_s implements
that.

> * Is it correct that there is no way to receive broadcast data frames in 
> AP mode?

Well, we could hack out the check, but it wouldn't necessarily fix the
issue. So I'd say generally, the answer is yes.

> * Is there any documentation or example code on using adhoc mode with 
> nl80211?

Only whatever is in wpa_supplicant for secure IBSS. I don't think the
'secure' part is really a requirement, but it's been ages.

> * Any general advice on moving forward?

In the past you could maybe have used 'cooked monitor' but we removed
that, so now I guess the best you could do in AP mode is to add a
monitor interface (you already say that's how some frames are
transmitted, though that doesn't actually seem necessary) and listen for
the data frames there? If the hardware/firmware actually receives them,
you should be able to see them there. If not, well, then it just can't
work in AP mode anyway.

(I suspect, for example, that Intel hardware generally won't give you
the frames, but I haven't tested it now.)


In a way the bigger question is what do the consoles expect from the AP?
Do they, for example, go into powersave and expect traffic to be
buffered for them? Because in that case IBSS won't work anyway, and it
seems a bit hard to imagine they wouldn't...

Or could you maybe simply not care and always make one of them the AP,
perhaps unless there's no real console anyway, and then you have no
powersave expectations on the Linux side from IBSS?

johannes

Re: Receiving broadcast data frames in AP mode

[Yannik Marchand]

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 :)

Kind regards,
Yannik Marchand

On 13/02/2026 16:13, Yannik Marchand wrote:
> Hello,
>
> Thank you for these insights. I want to provide a quick status update.
>
> 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.
>
> Unfortunately, using an interface in IBSS mode did not work, because 
> none of my hardware supports receiving association requests in IBSS mode.
>
> 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.
>
> Then, I tried implementing the entire protocol in monitor mode. While 
> I have learned a lot, this turned out to be quite hard.
>
> 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.
>
> There are still some issues currently. For example, after sending 
> around 12 packets to the Nintendo Switch, the Nintendo Switch seems to 
> stop receiving packets. However, I am happy that I'm getting closer to 
> finding a working solution.
>
> Kind regards,
> Yannik Marchand
>
> On 07/10/2025 11:47, Johannes Berg wrote:
>> Hi,
>>
>>> I have been using nl80211 to implement local wireless communication 
>>> with
>>> a Nintendo Switch device. The current implementation can be found here:
>>> https://github.com/kinnay/LDN.
>>
>> :)
>>
>>> We have run into the issue that we are not receiving any data frames in
>>> AP mode. In station mode it works fine. Inspecting the traffic with
>>> Wireshark in monitor mode showed that the data frames are being sent to
>>> the broadcast address ff:ff:ff:ff:ff:ff. Some research suggested that
>>> the Linux kernel might drop these packets by design:
>>> https://github.com/torvalds/linux/blob/7f7072574127c9e971cad83a0274e86f6275c0d5/net/mac80211/rx.c#L4443. 
>>>
>>
>> Yes, a real AP will never receive broadcast data frames, since it
>> controls the BSS and all traffic flows through it. In fact, hardware or
>> firmware would likely filter them as well, so even removing this check
>> may not address this for all devices.
>>
>>> Currently, we are wondering if it is necessary to switch to adhoc mode.
>>
>> That might not be a bad idea, but then you don't have control over which
>> station is sending beacons - though I guess if you actually have
>> multiple Linux hosts it wouldn't matter so much?
>>
>>> This would be inconvenient, as not all devices support adhoc mode,
>>
>> Not all devices support AP mode either, and see above wrt. filtering, so
>> I think either way you don't have some devices.
>>
>>>   and I
>>> am also not sure how adhoc mode can be used correctly. We do need to
>>> send beacon frames, and process association requests, but
>>> NL80211_CMD_START_AP and NL80211_CMD_SET_BEACON seem to be unsupported
>>> in adhoc mode.
>>
>> I don't know what you need from the beacon - almost sounds like not much
>> - so might not need SET_BEACON rather than JOIN_IBSS. Managing stations
>> from userspace is supported for secure IBSS though, wpa_s implements
>> that.
>>
>>> * Is it correct that there is no way to receive broadcast data 
>>> frames in
>>> AP mode?
>>
>> Well, we could hack out the check, but it wouldn't necessarily fix the
>> issue. So I'd say generally, the answer is yes.
>>
>>> * Is there any documentation or example code on using adhoc mode with
>>> nl80211?
>>
>> Only whatever is in wpa_supplicant for secure IBSS. I don't think the
>> 'secure' part is really a requirement, but it's been ages.
>>
>>> * Any general advice on moving forward?
>>
>> In the past you could maybe have used 'cooked monitor' but we removed
>> that, so now I guess the best you could do in AP mode is to add a
>> monitor interface (you already say that's how some frames are
>> transmitted, though that doesn't actually seem necessary) and listen for
>> the data frames there? If the hardware/firmware actually receives them,
>> you should be able to see them there. If not, well, then it just can't
>> work in AP mode anyway.
>>
>> (I suspect, for example, that Intel hardware generally won't give you
>> the frames, but I haven't tested it now.)
>>
>>
>> In a way the bigger question is what do the consoles expect from the AP?
>> Do they, for example, go into powersave and expect traffic to be
>> buffered for them? Because in that case IBSS won't work anyway, and it
>> seems a bit hard to imagine they wouldn't...
>>
>> Or could you maybe simply not care and always make one of them the AP,
>> perhaps unless there's no real console anyway, and then you have no
>> powersave expectations on the Linux side from IBSS?
>>
>> johannes
>

Re: Receiving broadcast data frames in AP mode

[Yannik Marchand]

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

Re: Receiving broadcast data frames in AP mode

[Johannes Berg]

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