Re: Receiving broadcast data frames in AP mode

[Yannik Marchand <ymarchand@me.com>]

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
>