Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

Hi,

On Fri, Jan 27, 2023 at 2:52 PM Michael Richardson [off-list ref] wrote:

Alexander Aring [off-list ref] wrote:
    >> - MLME ops without feedback constraints like beacons -> should go
    >> through the hot path, but not through the whole net stack, so
    >> ieee802154_subif_start_xmit()
    >>

    > it will bypass the qdisc handling (+ some other things which are around
    > there). The current difference is what I see llsec handling and other
    > things which might be around there? It depends if other "MLME-ops" need
    > to be e.g. encrypted or not.

I haven't followed the whole thread.
So I am neither agreeing nor disagreeing, just clarifying.
Useful beacons are "signed" (have integrity applied), but not encrypted.

I see. But that means they need to be going through llsec, just the
payload isn't encrypted and the MIC is appended to provide integrity.

It's important for userspace to be able to receive them, even if we don't
have a key that can verify them.  AFAIK, we have no specific interface to
receive beacons.

This can be done over multiple ways. Either over a socket
communication or if they appear rarely we can put them into a netlink
event. In my opinion we already put that in a higher level API in
passive scan to interpret the receiving of a beacon on kernel level
and trigger netlink events.

I am not sure how HardMAC transceivers handle them on the transceiver
side only or if they ever provide them to the next layer or not?
For SoftMAC you can actually create a AF_PACKET raw socket, and you
should see everything which bypass hardware address filters and kernel
filters. Then an application can listen to them.

- Alex