Message-ID: <20220609175217.21a9acee@xps-13>
Date:   Thu, 9 Jun 2022 17:52:17 +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 - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Network Development <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>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next 1/6] net: ieee802154: Drop coordinator
 interface type

Hi Alexander,

aahringo@...hat.com wrote on Wed, 8 Jun 2022 21:56:53 -0400:

> Hi,
> 
> On Wed, Jun 8, 2022 at 9:47 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Hi Alex,
> >  
> > > > 3. coordinator (any $TYPE specific) userspace software
> > > >
> > > > May the main argument. Some coordinator specific user space daemon
> > > > does specific type handling (e.g. hostapd) maybe because some library
> > > > is required. It is a pain to deal with changing roles during the
> > > > lifetime of an interface and synchronize user space software with it.
> > > > We should keep in mind that some of those handlings will maybe be
> > > > moved to user space instead of doing it in the kernel. I am fine with
> > > > the solution now, but keep in mind to offer such a possibility.
> > > >
> > > > I think the above arguments are probably the same why wireless is
> > > > doing something similar and I would avoid running into issues or it's
> > > > really difficult to handle because you need to solve other Linux net
> > > > architecture handling at first.  
> > >
> > > Yep.  
> >
> > The spec makes a difference between "coordinator" and "PAN
> > coordinator", which one is the "coordinator" interface type supposed to
> > picture? I believe we are talking about being a "PAN coordinator", but
> > I want to be sure that we are aligned on the terms.
> >  
> 
> I think it depends what exactly the difference is. So far I see for
> address filtering it should be the same. Maybe this is an interface
> option then?

The difference is that the PAN coordinator can decide to eg. refuse an
association, while the other coordinators, are just FFDs with no
specific decision making capability wrt the PAN itself, but have some
routing capabilities available for the upper layers.

The most I look into this, the less likely it is that the Linux stack
will drive an RFD. Do you think it's worth supporting them? Because if
we don't:
* NODE == FFD which acts as coordinator
* COORD == FFD which acts as the PAN coordinator

> > > > > > You are mixing things here with "role in the network" and what
> > > > > > the transceiver capability (RFD, FFD) is, which are two
> > > > > > different things.  
> > > > >
> > > > > I don't think I am, however maybe our vision differ on what an
> > > > > interface should be.
> > > > >  
> > > > > > You should use those defines and the user needs to create a new
> > > > > > interface type and probably have a different extended address
> > > > > > to act as a coordinator.  
> > > > >
> > > > > Can't we just simply switch from coordinator to !coordinator
> > > > > (that's what I currently implemented)? Why would we need the user
> > > > > to create a new interface type *and* to provide a new address?
> > > > >
> > > > > Note that these are real questions that I am asking myself. I'm
> > > > > fine adapting my implementation, as long as I get the main idea.
> > > > >  
> > > >
> > > > See above.  
> > >
> > > That's okay for me. I will adapt my implementation to use the
> > > interface thing. In the mean time additional details about what a
> > > coordinator interface should do differently (above question) is
> > > welcome because this is not something I am really comfortable with.  
> >
> > I've updated the implementation to use the IFACE_COORD interface and it
> > works fine, besides one question below.
> >
> > Also, I read the spec once again (soon I'll sleep with it) and
> > actually what I extracted is that:
> >
> > * A FFD, when turned on, will perform a scan, then associate to any PAN
> >   it found (algorithm is beyond the spec) or otherwise create a PAN ID
> >   and start its own PAN. In both cases, it finishes its setup by
> >   starting to send beacons.
> >  
> 
> What does it mean "algorithm is beyond the spec" - build your own?

This is really what is in the spec, I suppose it means "do what you
want in your use case".

What I have in mind: when a device is powered on and detects two PANs,
well, it can join whichever it wants, but perhaps we should make the
decision based on the LQI information we have (the closer the better).

> > * A RFD will behave more or less the same, without the PAN creation
> >   possibility of course. RFD-RX and RFD-TX are not required to support
> >   any of that, I'll assume none of the scanning features is suitable
> >   for them.
> >
> > I have a couple of questions however:
> >
> > - Creating an interface (let's call it wpancoord) out of wpan0 means
> >   that two interfaces can be used in different ways and one can use
> >   wpan0 as a node while using wpancoord as a PAN coordinator. Is that
> >   really allowed? How should we prevent this from happening?
> >  
> 
> When the hardware does not support it, it should be forbidden. As most
> transceivers have only one address filter it should be forbidden
> then... but there exists a way to indeed have such a setup (which you
> probably don't need to think about). It's better to forbid something
> now, with the possibility later allowing it. So it should not break
> any existing behaviour.

Done, thanks to the pointer you gave in the other mail.

> 
> > - Should the device always wait for the user(space) to provide the PAN
> >   to associate to after the scan procedure right after the
> >   add_interface()? (like an information that must be provided prior to
> >   set the interface up?)
> >
> > - How does an orphan FFD should pick the PAN ID for a PAN creation?
> >   Should we use a random number? Start from 0 upwards? Start from
> >   0xfffd downwards? Should the user always provide it?
> >  
> 
> I think this can be done all with some "fallback strategies" (build
> your own) if it's not given as a parameter.

Ok, In case no PAN is found, and at creation no PAN ID is provided, we
can default to 0.

> > - Should an FFD be able to create its own PAN on demand? Shall we
> >   allow to do that at the creation of the new interface?
> >  
> 
> I thought the spec said "or otherwise"? That means if nothing can be
> found, create one?

Ok, so we assume this is only at startup, fine. But then how to handle
the set_pan_id() call? I believe we can forbid any set_pan_id() command
to be run while the interface is up. That would ease the handling.
Unless I am missing something?

Thanks,
Miquèl

Powered by blists - more mailing lists