lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 10 Jan 2022 12:17:00 -0500
From:   Alexander Aring <>
To:     Miquel Raynal <>
Cc:     Stefan Schmidt <>,
        Nicolas Schodet <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        "open list:NETWORKING [GENERAL]" <>,
        linux-wpan - ML <>,
        David Girault <>,
        Romuald Despres <>,
        Frederic Blain <>,
        Thomas Petazzoni <>,
        kernel list <>
Subject: Re: [net-next 12/18] net: mac802154: Handle scan requests


On Fri, 7 Jan 2022 at 06:02, Miquel Raynal <> wrote:
> > >
> >
> > Okay, I will look at this code closely regarding whenever multiple
> > wpan_devs are running.
> The "scanning" boolean is stored as a wpan_phy member (IIRC) so we
> should be good on this regard (now that I have a clearer picture of the
> dependencies).


> > You should also check for possible stop of all possible wpan dev
> > transmit queues, if it's not already done.
> I forgot about this path. Indeed I'll add a check in the transmit path
> as well, of course.

What I mean is look into the functions "ieee802154_stop_queue()" and

> > I suppose a scan can take a
> > long time and we should not send some data frames out. I am thinking
> > about the long time scan operation... if we stop the queue for a long
> > time I think we will drop a lot, however the scan can only be
> > triggered by the right permissions and the user should be aware of the
> > side effects. Proper reliable upper layer protocols will care or non
> > reliable will not care about this.
> >
> > There still exists the driver "ca8210" which is the mentioned HardMAC
> > transceiver in SoftMAC. There should somehow be a flag that it cannot
> > do a scan and the operation should not be allowed as the xmit callback
> > allows dataframes only.
> So it cannot do an active scan, but a passive scan would be allowed
> (there is no transmission, and the beacons are regular valid frames,
> I suppose they should not be filtered out by the hardware).
> So we actually need these hooks back :-) Because the right thing to do
> here is to use the "FYI here is the scan op that is starting" message
> from the mac to the drivers and this driver should return "nope,
> -ENOTSUPP". The mac would react in this case by canceling the
> operation and returning an error to the caller. Same when sending
> beacons if we consider beacons as !dataframes.

I believe that a HardMAC transceiver will handle a lot of the scan
process on the transceiver side and is only capable of dumping what
it's stored and start/stop scan? This is one reason why the
scan/dump/etc cfg802154 interface  should be close to the standard
(MLME). At the end it should from userspace make no difference if at
the end is a HardMAC or SoftMAC. Although there will always be a
limitation and a SoftMAC is probably always "more" powerful than a
HardMAC, but at some point there is a "minimum" of capable
functionality... and SoftMAC transceivers might always have "some"
things which they might offload to the hardware.

- Alex

Powered by blists - more mailing lists