Message-ID: <20220620111922.51189382@xps-13>
Date:   Mon, 20 Jun 2022 11:19:22 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <aahringo@...hat.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        Alexander Aring <alex.aring@...il.com>,
        linux-wpan - ML <linux-wpan@...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>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH wpan-next 1/6] net: ieee802154: Drop coordinator
 interface type

Hi Alexander,

aahringo@...hat.com wrote on Sun, 19 Jun 2022 20:13:08 -0400:

> Hi,
> 
> On Fri, Jun 17, 2022 at 11:13 AM Miquel Raynal
> <miquel.raynal@...tlin.com> wrote:
> >
> > Hi Alex,
> >
> > aahringo@...hat.com wrote on Sat, 11 Jun 2022 08:23:41 -0400:
> >  
> > > Hi,
> > >
> > > On Thu, Jun 9, 2022 at 11:52 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:  
> > > >
> > > > 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.
> > > >  
> > >
> > > As I said, if there is a behaviour "it can do xxx, but the spec
> > > doesn't give more information about it" this smells for me like things
> > > moving into the user space. This can also be done e.g. by a filtering
> > > mechanism, _just_ the user will configure how this filtering will look
> > > like.
> > >  
> > > > 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
> > > >  
> > >
> > > I thought that this is a kind of "transceiver type capability " e.g. I
> > > can imagine if it's only a "RFD" transceiver then you would be e.g.
> > > not able to set the address filter to coordinator capability. However
> > > I think that will never happen for a SoftMAC transceiver because why
> > > not adding a little bit silicon to provide that? People also can
> > > always have a co-processor and run the transceiver in promiscuous
> > > mode. E.g. atusb (which makes this transceiver poweful, because we
> > > have control over the firmware).
> > >
> > > For me node != coord, because the address filtering is different. As I
> > > mentioned in another mail "coordinator" vs "PAN coordinator" as
> > > described is what the user is doing here on top of it.
> > >  
> > > > > > > > > > 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).
> > > >  
> > >
> > > As I said in the other mail, this smells more and more for me to move
> > > this handling to user space. The kernel therefore supports operations
> > > to trigger the necessary steps (scan/assoc/etc.)
> > >  
> > > > > > * 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.
> > > >  
> > >
> > > See me for other mails. (user space job)
> > >  
> > > > > > - 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?
> > > >  
> > >
> > > See my other mails (user space job).  
> >
> > Ok then, I'll go with the following constraints in mind:
> >
> > SCAN (passive/active) (all devices)
> > - All devices are allowed to perform scans.
> > - The user decides when a scan must be performed, there is no
> >   limitation on when to do a scan (but the interface must be up for
> >   physical reasons).  
> 
> Yes, I think it should not have anything to do with interface
> limitation.... it needs to have an operating phy.

Yes

> However I can say
> more to this when I see code (but please don't provide me with any
> github repository, I mean here on the mailing list and not a more than
> 15 patches stack, Thanks.) You probably want to say on an user level
> "run scan for iface $FOO" but this is just to make it simpler.
> 
> > PAN ID
> > - The user is responsible to set the PAN ID.  
> 
> This is currently the case and I don't see a reason to change it.
> 
> > - Like several other parameters, the PAN ID can only be changed if the
> >   iface is down. Which means the user might need to do:
> >         link up > scan > link down > set params > link up  
> 
> Yes, changing this behaviour will break other things.
> 
> > BEACON
> > - Coordinator interfaces only can send beacons.  
> 
> okay.
> 
> > - Beacons can only be sent when part of a PAN (PAN ID != 0xffff).  
> 
> I guess that 0xffff means no pan is set and if no pan is set there is no pan?

Yes, Table 8-94—MAC PIB attributes states:

	"The identifier of the PAN on which the device is operating. If
	this value is 0xffff, the device is not associated."

> > - The choice of the beacon interval is up to the user, at any moment.
> > OTHER PARAMETERS  
> 
> I would say "okay", there might be an implementation detail about when
> it's effective.
> But is this not only required if doing such "passive" mode?

The spec states that a coordinator can be in one of these 3 states:
- Not associated/not in a PAN yet: it cannot send beacons nor answer
  beacon requests
- Associated/in a PAN and in this case:
    - It can be configured to answer beacon requests (for other
      devices performing active scans)
    - It can be configured to send beacons "passively" (for other
      devices performing passive scans)

In practice we will let to the user the choice of sending beacons
passively or answering to beacon requests or doing nothing by adding a
fourth possibility:
    - The device is not configured, it does not send beacons, even when
      receiving a beacon request, no matter its association status.

> > - The choice of the channel (page, etc) is free until the device is
> >   associated to another, then it becomes fixed.
> >  
> 
> I would say no here, because if the user changes it it's their
> problem... it's required to be root for doing it and that should be
> enough to do idiot things?

That was a proposal to match the spec, but I do agree we can let the
user handle this, so I won't add any checks regarding channel changes.

> > ASSOCIATION (to be done)
> > - Device association/disassociation procedure is requested by the
> >   user.  
> 
> This is similar like wireless is doing with assoc/deassoc to ap.

Kind of, yes.

> > - Accepting new associations is up to the user (coordinator only).  
> 
> Again implementation details how this should be realized.

Any coordinator can decide whether new associations are possible or
not. There is no real use case besides this option besides the memory
consumption on limited devices. So either we say "we don't care about
that possible limitation on Linux systems" or "let's add a user
parameter which tells eg. the number of devices allowed to associate".

What's your favorite?

> > - If the device has no parent (was not associated to any device) it is
> >   PAN coordinator and has additional rights regarding associations.
> >  
> 
> No idea what a "device' here is, did we not made a difference between
> "coordinator" vs "PAN coordinator" before and PAN is that thing which
> does some automatically scan/assoc operation and the other one not? I
> really have no idea what "device" here means.

When implementing association, we need to keep track of the
parent/child relationship because we may expect coordinators to
propagate messages from leaf node up to their parent. A device without
parent is then the PAN coordinator. Any coordinator may advertise the
PAN and subsequent devices may attach to it, this is creating a tree of
nodes.

The sentence about the additional rights is wrong, however, the spec
does not state anything about it, it was a misinterpretation on my side.

Thanks,
Miquèl

Powered by blists - more mailing lists