Hi,
On Tue, Feb 14, 2023 at 9:28 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
> 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?
>
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)
> > 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?
- Alex
