Message-ID: <20230217095251.59c324d0@xps-13>
Date:   Fri, 17 Feb 2023 09:52:51 +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 Thu, 16 Feb 2023 23:46:42 -0500:

> Hi,
> 
> On Tue, Feb 14, 2023 at 9:28 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > 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?
> >  
> 
> good question...
> 
> > 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.
> >  
> 
> I would capture and deliver everything to the user.. if the user does
> a scan while doing whatever the user is doing with the monitor
> interface at this time, the user need to live with the consequences
> and you need to be root (okay probably every wireless manager will
> give the normal user access to it, but still you need to know what you
> are doing)

Fair enough.

> > > 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...
> >  
> 
> ok, I am curious. Probably it is very driver/device specific but yea,
> HardMAC needs to at least support what 802.15.4 says, the rest is
> optional and result in -ENOTSUPP?

TBH this is still a gray area in my mental model. I'm not sure what
these devices will really offer in terms of interfaces.

Thanks,
Miquèl

Powered by blists - more mailing lists