netdev - Re: [PATCH wpan-next] mac802154: Allow the creation of coordinator interfaces

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221024141601.218b68e2@xps-13>
Date:   Mon, 24 Oct 2022 14:16:01 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <aahringo@...hat.com>
Cc:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Guilhem Imberton <guilhem.imberton@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next] mac802154: Allow the creation of coordinator
 interfaces

Hi Alexander,

> > About the way we handle the PAN coordinator role I have a couple of
> > questions:
> > - shall we consider only the PAN coordinator to be able to accept
> >   associations or is any coordinator in the PAN able to do it? (this is
> >   not clear to me)  
> 
> Me either, it sounds for me that coordinators are "leaves" and pan
> coordinators are not. It is like in IPv6 level it is a host or router.

I went through the spec once again and I actually (re)discovered
Annexe E "Time-slot relaying based link extension (TRLE)" which indeed
seems to tell us that relaying is an extension, so otherwise
coordinators are "leaves" as you say.

> > - If a coordinator receives a packet with no destination it should
> >   expect it to be targeted at the PAN controller. Should we consider
> >   relaying the packet?  
> 
> I guess it depends what the standard says here?

While we don't implement TRLE (and this is a project on its own) I
guess we should not perform any relaying.

> > - Is relaying a hardware feature or should we do it in software?
> >  
> 
> I think for SoftMAC it is only the address filter which needs to be
> changed. The rest is in software. So far what I can see here.

If we need to change the address filters then I guess the hardware is
broken, it would not be usable. The hardware must have a "PAN
controller" bit to know whether or not the packet must be dropped or
not when there is no destination field.

> Question is what we are using here in the Linux kernel to provide such
> functionality...
> 
> e.g. see:
> 
> include/net/dst.h
>
> > Regarding the situation where we would have NODE + MONITOR or COORD +
> > MONITOR, while the interface creation would work, both could not be
> > open at the same time because the following happens:
> > mac802154_wpan_open() {
> >         ieee802154_check_concurrent_iface() {
> >                 ieee802154_check_mac_settings() {
> >                         /* prevent the two interface types from being
> >                          * open at the same time because the filtering
> >                          * needs are not compatible. */
> >                 }
> >         }
> > }
> >
> > Then, because you asked me to anticipate if we ever want to support more
> > than one NODE or COORD interface at the same time, or at least not to
> > do anything that would lead to a step back on this regard, I decided I
> > would provide all the infrastructure to gracefully handle this
> > situation in the Rx path, even though right now it still cannot happen
> > because when opening an interface, ieee802154_check_concurrent_iface()
> > will also prevent two NODE / COORD interfaces to be opened at the same
> > time.  
> 
> yes, but you are assuming the actual hardware here. A hardware with
> multiple address filters can indeed support other interfaces at the
> same time. I can also name one, hwsim and a real one - atusb.

I have this use case in mind, I know the support for it may be
brought at some point, and I think my proposal is future proof on this
aspect. Isn't it?

Thanks,
Miquèl