linux-kernel - Re: [net-next 17/18] net: mac802154: Let drivers provide their own beacons implementation

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 linux-cve-announce 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]

Message-ID: <20220107084029.21f341a4@xps13>
Date:   Fri, 7 Jan 2022 08:40:29 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     David Girault <David.Girault@...vo.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        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 17/18] net: mac802154: Let drivers provide their own
 beacons implementation

Hi Alexander,

alex.aring@...il.com wrote on Thu, 6 Jan 2022 23:21:45 -0500:

> Hi,
> 
> On Thu, 6 Jan 2022 at 14:15, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Hi Alexander,
> >
> > alex.aring@...il.com wrote on Wed, 5 Jan 2022 19:23:04 -0500:
> >  
> ...
> > >
> > > A HardMAC driver does not use this driver interface... but there
> > > exists a SoftMAC driver for a HardMAC transceiver. This driver
> > > currently works because we use dataframes only... It will not support
> > > scanning currently and somehow we should make iit not available for
> > > drivers like that and for drivers which don't set symbol duration.
> > > They need to be fixed.  
> >
> > My bad. I did not look at it correctly. I made a mistake when talking
> > about a hardMAC.
> >
> > Instead, it is a "custom" low level MAC layer. I believe we can compare
> > the current mac802154 layer mostly to the MLME that is mentioned in the
> > spec. Well here the additional layer that needs these hooks would be
> > the MCPS. I don't know if this will be upstreamed or not, but the need
> > for these hooks is real if such an intermediate low level MAC layer
> > gets introduced.
> >
> > In v2 I will get rid of the two patches adding "driver access" to scans
> > and beacons in order to facilitate the merge of the big part. Then we
> > will have plenty of time to discuss how we can create such an interface.
> > Perhaps I'll be able to propose more code as well to make use of these
> > hooks, we will see.
> >  
> 
> That the we have a standardised interface between Ieee802154 and
> (HardMAC or SoftMAC(mac802154)) (see cfg802154_ops) which is defined
> according the spec would make it more "stable" that it will work with
> different HardMAC transceivers (which follows that interface) and
> mac802154 stack (which also follows that interface). If I understood
> you correctly.


I am not sure. I am really talking about a softMAC. I am not sure
where to put that layer "vertically" but according to the spec the MCPS
(MAC Common Part Sublayer) is the layer that contains the data
primitives, while MLME has been designed for management and
configuration.

> I think this is one reason why we are not having any HardMAC
> transceivers driver supported in a proper way yet.
> 
> I can also imagine about a hwsim HardMAC transceiver which redirects
> cfg802154 to mac802154 SoftMAC instance again (something like that),
> to have a virtual HardMAC transceiver for testing purpose, etc. In
> theory that should work...

Yeah I see what you mean, but IMHO that's basically duplicating the
softMAC layer, we already have hwsim wired to cfg802154 through
mac802154. In a certain way we could argue that this is a hardMAC =)

Thanks,
Miquèl