Hi Alexander,
aahringo@xxxxxxxxxx wrote on Tue, 14 Feb 2023 08:51:12 -0500:
> Hi,
>
> On Mon, Feb 13, 2023 at 5:16 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> >
> > Hi Alexander,
> >
> > > > > > > > +static int nl802154_trigger_scan(struct sk_buff *skb, struct genl_info *info)
> > > > > > > > +{
> > > > > > > > + struct cfg802154_registered_device *rdev = info->user_ptr[0];
> > > > > > > > + struct net_device *dev = info->user_ptr[1];
> > > > > > > > + struct wpan_dev *wpan_dev = dev->ieee802154_ptr;
> > > > > > > > + struct wpan_phy *wpan_phy = &rdev->wpan_phy;
> > > > > > > > + struct cfg802154_scan_request *request;
> > > > > > > > + u8 type;
> > > > > > > > + int err;
> > > > > > > > +
> > > > > > > > + /* Monitors are not allowed to perform scans */
> > > > > > > > + if (wpan_dev->iftype == NL802154_IFTYPE_MONITOR)
> > > > > > > > + return -EPERM;
> > > > > > >
> > > > > > > btw: why are monitors not allowed?
> > > > > >
> > > > > > I guess I had the "active scan" use case in mind which of course does
> > > > > > not work with monitors. Maybe I can relax this a little bit indeed,
> > > > > > right now I don't remember why I strongly refused scans on monitors.
> > > > >
> > > > > Isn't it that scans really work close to phy level? Means in this case
> > > > > we disable mostly everything of MAC filtering on the transceiver side.
> > > > > Then I don't see any reasons why even monitors can't do anything, they
> > > > > also can send something. But they really don't have any specific
> > > > > source address set, so long addresses are none for source addresses, I
> > > > > don't see any problem here. They also don't have AACK handling, but
> > > > > it's not required for scan anyway...
> > > >
> > > > I think I remember why I did not want to enable scans on monitors: we
> > > > actually change the filtering level to "scan", which is very
> > > > different to what a monitor is supposed to receive, which means in scan
> > > > mode a monitor would no longer receive all what it is supposed to
> > > > receive. Nothing that cannot be workaround'ed by software, probably,
> > > > but I believe it is safer right now to avoid introducing potential
> > > > regressions. So I will just change the error code and still refuse
> > > > scans on monitor interfaces for now, until we figure out if it's
> > > > actually safe or not (and if we really want to allow it).
> > > >
> > >
> > > Okay, for scan yes we tell them to be in scan mode and then the
> > > transceiver can filter whatever it delivers to the next level which is
> > > necessary for filtering scan mac frames only. AACK handling is
> > > disabled for scan mode for all types != MONITORS.
> > >
> > > For monitors we mostly allow everything and AACK is _always_ disabled.
> > > The transceiver filter is completely disabled for at least what looks
> > > like a 802.15.4 MAC header (even malformed). There are some frame
> > > length checks which are necessary for specific hardware because
> > > otherwise they would read out the frame buffer. For me it can still
> > > feed the mac802154 stack for scanning (with filtering level as what
> > > the monitor sets to, but currently our scan filter is equal to the
> > > monitor filter mode anyway (which probably can be changed in
> > > future?)). So in my opinion the monitor can do both -> feed the scan
> > > mac802154 deliver path and the packet layer. And I also think that on
> > > a normal interface type the packet layer should be feeded by those
> > > frames as well and do not hit the mac802154 layer scan path only.
> >
> > Actually that would be an out-of-spec situation, here is a quote of
> > chapter "6.3.1.3 Active and passive channel scan"
> >
> > During an active or passive scan, the MAC sublayer shall
> > discard all frames received over the PHY data service that are
> > not Beacon frames.
> >
>
> Monitor interfaces are not anything that the spec describes, it is
> some interface type which offers the user (mostly over AF_PACKET raw
> socket) full phy level access with the _default_ options. I already
> run user space stacks (for hacking/development only) on monitor
> interfaces to connect with Linux 802.15.4 interfaces, e.g. see [0]
> (newer came upstream, somewhere I have also a 2 years old updated
> version, use hwsim not fakelb).
:-)
>
> In other words, by default it should bypass 802.15.4 MAC and it still
> conforms with your spec, just that it is in user space. However, there
> exists problems to do that, but it kind of works for the most use
> cases. I said here by default because some people have different use
> cases of what they want to do in the kernel. e.g. encryption (so users
> only get encrypted frames, etc.) We don't support that but we can,
> same for doing a scan. It probably requires just more mac802154 layer
> filtering.
>
> There are enough examples in wireless that they do "crazy" things and
> you can do that only with SoftMAC transceivers because it uses more
> software parts like mac80211 and HardMAC transceivers only do what the
> spec says and delivers it to the next layer. Some of them have more
> functionality I guess, but then it depends on driver implementation
> and a lot of other things.
>
> Monitors also act as a sniffer device, but you _could_ also send
> frames out and then the fun part begins.
Yes, you're right, it's up to us to allow monitor actions.
> > I don't think this is possible to do anyway on devices with a single
> > hardware filter setting?
> >
>
> On SoftMAC it need to support a filtering level where we can disable
> all filtering and get 802.15.4 MAC frames like it's on air (even
> without non valid checksum, but we simply don't care if the
> driver/transceiver does not support it we will always confirm it is
> correct again until somebody comes around and say "oh we can do FCS
> level then mac802154 does not need to check on this because it is
> always correct")... This is currently the NONE filtering level I
> think?
But right now we ask for the "scan" filtering, which kind of discards
most frames. Would you like a special config for monitors, like
receiving everything on each channel you jump on? Or shall we stick to
only transmitting beacon frames during a scan on a monitor interface?
I guess it's rather easy to handle in each case. Just let me know what
you prefer. I think I have a small preference for the scan filtering
level, but I'm open.
> For HardMAC it is more complicated; they don't do that, they do the
> "scan" operation on their transceiver and you can dump the result and
> probably never forward any beacon related frames? (I had this question
> once when Michael Richardson replied).
Yes, in this case we'll have to figure out something else...
>
> - Alex
>
> [0] https://github.com/RIOT-OS/RIOT/pull/5582
>
Thanks,
Miquèl
