netdev - 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] [day] [month] [year] [list]

Message-ID: <CAB_54W7kL6XnZxVXKudWXqMa=HVm=dk5ydAy6Ec4iMoU9mCNKA@mail.gmail.com>
Date:   Tue, 11 Jan 2022 08:43:51 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.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,

On Fri, 7 Jan 2022 at 02:40, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> 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.
>

ok.

> > 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 =)

Would be good to show people "here is how to write a HardMAC
driver..." if this is even possible without any change yet.

- Alex