Message-ID: <CAK-6q+jP55MaB-_ZbRHKESgEb-AW+kN3bU2SMWMtkozvoyfAwA@mail.gmail.com>
Date:   Tue, 14 Feb 2023 08:51:12 -0500
From:   Alexander Aring <aahringo@...hat.com>
To:     Miquel Raynal <miquel.raynal@...tlin.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,

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.

> 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?

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).

- Alex

[0] https://github.com/RIOT-OS/RIOT/pull/5582

Powered by blists - more mailing lists