lists.openwall.net | 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
| ||
|
Date: Mon, 10 Jan 2022 12:17:00 -0500 From: Alexander Aring <alex.aring@...il.com> To: Miquel Raynal <miquel.raynal@...tlin.com> Cc: Stefan Schmidt <stefan@...enfreihafen.org>, Nicolas Schodet <nico@...fr.eu.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>, linux-wpan - ML <linux-wpan@...r.kernel.org>, David Girault <david.girault@...vo.com>, Romuald Despres <romuald.despres@...vo.com>, Frederic Blain <frederic.blain@...vo.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, kernel list <linux-kernel@...r.kernel.org> Subject: Re: [net-next 12/18] net: mac802154: Handle scan requests Hi, On Fri, 7 Jan 2022 at 06:02, Miquel Raynal <miquel.raynal@...tlin.com> 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). > ok. > > 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 "ieee802154_wake_queue()". > > 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