netdev - Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way supported channels are declared

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]

Date:   Wed, 2 Mar 2022 14:21:38 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>
Subject: Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way
 supported channels are declared

Hi Alexander,

alex.aring@...il.com wrote on Sun, 20 Feb 2022 18:05:39 -0500:

> Hi,
> 
> On Mon, Feb 7, 2022 at 2:49 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Hi Alexander,
> >
> > alex.aring@...il.com wrote on Sun, 6 Feb 2022 16:37:23 -0500:
> >  
> > > Hi,
> > >
> > > On Tue, Feb 1, 2022 at 9:55 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > > ...  
> > > >
> > > > Given the new information that I am currently processing, I believe the
> > > > array is not needed anymore, we can live with a minimal number of
> > > > additional helpers, like the one getting the PRF value for the UWB
> > > > PHYs. It's the only one I have in mind so far.  
> > >
> > > I am not really sure if I understood now. So far those channel/page
> > > combinations are the same because we have no special "type" value in
> > > wpan_phy,  
> >
> > Yes, my assumption was more: I know there are only -legacy- phy types
> > supported, we will add another (or improve the current) way of defining
> > channels when we'll need to. Eg when improving UWB support.
> >  
> > > what we currently support is the "normal" (I think they name
> > > it legacy devices) phy type (no UWB, sun phy, whatever) and as Channel
> > > Assignments says that it does not apply for those PHY's I think it
> > > there are channel/page combinations which are different according to
> > > the PHY "type". However we don't support them and I think there might
> > > be an upcoming type field in wpan_phy which might be set only once at
> > > registration time.  
> >
> > An idea might be to create a callback that drivers might decide to
> > implement or not. If they implement it, the core might call it to get
> > further information about the channels. The core would provide a {page,
> > channel} couple and retrieve a structure with many information such as
> > the the frequency, the protocol, eventually the prf, etc.
> >  
> 
> As I said before, for "many information" we should look at how
> wireless is using that with regdb and extend it with 802.15.4
> channels/etc. The kernel should only deal with an unique
> identification of a database key for "regdb" which so far I see is a
> combination of phy type, page id and channel id. Then from "somewhere"
> also the country code gets involved into that and you get a subset of
> what is available.

Do you want another implementation of regdb that would support the
802.15.4 world only (so far it is highly 802.11 oriented) ? Or is this
something that you would like to merge in the existing project?

Overall it can be useful to define what is allowed in different
countries but this will not save us from needing extra information from
the devices. Describing the channels and protocols (and PRFs) for an
UWB PHY has nothing to do with the regulatory database, it's just
listing what is supported by the device. The actual location where it
might be useful to have a regdb (but not mandatory at the beginning)
would be when changing channels to avoid messing with local
regulations, I believe?

Thanks,
Miquèl