Hi, On Fri, Jan 27, 2023 at 2:52 PM Michael Richardson <mcr@xxxxxxxxxxxx> wrote: > > > Alexander Aring <aahringo@xxxxxxxxxx> 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
