Message-ID: <20230214152849.5c3d196b@xps-13>
Date:   Tue, 14 Feb 2023 15:28:49 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <aahringo@...hat.com>
Cc:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Guilhem Imberton <guilhem.imberton@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next 1/6] ieee802154: Add support for user scanning
 requests

Hi Alexander,

aahringo@...hat.com wrote on Tue, 14 Feb 2023 08:51:12 -0500:

> Hi,
> 
> On Mon, Feb 13, 2023 at 5:16 AM Miquel Raynal <miquel.raynal@...tlin.com> 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

Powered by blists - more mailing lists