Re: Receiving broadcast data frames in AP mode

[Johannes Berg <johannes@sipsolutions.net>]

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