Message-ID: <20220627101759.6ec79a84@xps-13>
Date:   Mon, 27 Jun 2022 10:17:59 +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 Sat, 25 Jun 2022 21:36:05 -0400:

> Hi,
> 
> On Tue, Jun 21, 2022 at 2:27 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@...hat.com wrote on Mon, 20 Jun 2022 21:54:33 -0400:
> >  
> > > Hi,
> > >
> > > On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > > ...  
> > > > >  
> > > > > > - 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."
> > > >  
> > >
> > > I am not sure if I understand this correctly but for me sending
> > > beacons means something like "here is a pan which I broadcast around"  
> >
> > Yes, and any coordinator in a beacon enabled PAN is required to send
> > beacons to advertise the PAN after it associated.
> >  
> > > and then there is "'device' is not associated".  
> >  
> 
> I think there are several misunderstandings in the used terms in this
> discussion.
> 
> A "associated" device does not imply an association by using the mac
> commands, it can also be by setting a pan id manually without doing
> anything of communication.

Yes, I am referring to the association procedure here, but I agree it
can be done "statically", that's how it's been done in Linux so far
anyway.

> But this would for me just end in a term "has valid PAN id",
> association is using the mac commands.
> 
> > FFDs are not supposed to send any beacon if they are not part of a PAN.
> >  
> 
> FFD is a device capability (it can run as pan coordinator, which is a
> node with more functions), it is not a term which can be used in
> combination with an instance of a living role in the network
> (coordinator). That's for me what I understand in linux-wpan terms ->
> it's a coordinator interface.

I think we are aligned on the terms.

"Coordinators are not supposed to send any beacon if they are not part
of a PAN." if you prefer. But then while your are not connected to any
network, can we really talk about coordinator? A coordinator, as you
rightfully said, is a living role, so talking about a coordinator that
is not "associated" does not really make sense. Hence the generic term
"device", which I stretched a bit towards "FFD" because RFDs cannot
become coordinators on the network.

Anyway, I think we mean the same thing :)

> > > Is when "associated"
> > > (doesn't matter if set manual or due scan/assoc) does this behaviour
> > > implies "I am broadcasting my pan around, because my panid is !=
> > > 0xffff" ?  
> >
> > I think so, yes. To summarize:
> >
> > Associated:
> > * PAN is != 0xffff
> > * FFD can send beacons
> > Not associated:
> > * PAN is == 0xffff
> > * FFD cannot send beacons
> >  
> 
> But the user need to explicit enable the "reacting/sending (probably
> depends on active/passive) beacon feature" which indeed sounds fine to
> me.

Absolutely

> > > > > > - 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  
> > >
> > > so this will confirm, it should send beacons if panid != 0xffff (as my
> > > question above)?  
> >
> > It should only send beacons if in a beacon-enabled PAN. The spec is
> > not very clear about if this is mandatory or not.
> >  
> 
> as above. Sounds fine to me to have a setting start/stop for that.

Yes

> > > > - 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.
> > > >  
> > >
> > > Where is this "user choice"? I mean you handle those answers for
> > > beacon requests in the kernel?  
> >
> > Without user input, so the default state remains the same as today: do
> > not send beacons + do not answer beacon requests. Then, we created a:
> >
> >         iwpan dev xxx beacons send ...
> >
> > command which, depending on the beacon interval will either send
> > beacons at a given pace (interval < 15) or answer beacon requests
> > otherwise.
> >
> > If the user want's to get back to the initial state (silent device):
> >
> >         iwpan dev xxx beacons stop
> >  
> 
> sounds fine.
> 
> > > > > > - 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.
> > > >  
> > >
> > > okay.
> > >  
> > > > > > 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.
> > > >  
> > >
> > > In the sense of "by the user" you don't mean putting this logic into
> > > user space you want to do it in kernel and implement it as a
> > > netlink-op, the same as wireless is doing? I just want to confirm
> > > that. Of course everything else is different, but from this
> > > perspective it should be realized.  
> >
> > Yes absolutely, the user would have a command (which I am currently
> > writing) like:
> >
> > iwpan dev xxx associate pan_id yyy coord zzz
> > iwpan dev xxx disassociate device zzz
> >  
> 
> Can say more about that if I am seeing code.
> 
> > Mind the disassociate command which works for parents (you are
> > associated to a device and want to leave the PAN) and also for children
> > (a device is associated to you, and you request it to leave the PAN).
> >  
> > > > > > - 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?
> > > >  
> > >
> > > Sure there should be a limitation about how many pans should be
> > > allowed, that is somehow the bare minimum which should be there.
> > > I was not quite sure how the user can decide of denied assoc or not,
> > > but this seems out of scope for right now...  
> >
> > I thought as well about this, I think in the future we might find a way
> > to whitelist or blacklist devices and have these answers being sent
> > automatically by the kernel based on user lists, but this is really an
> > advanced feature and there is currently no use case yet, so I'll go for
> > the netlink op which changes the default number of devices which may
> > associate to a coordinator.  
> 
> yes.
> 
> > >  
> > > > > > - 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.
> > > >  
> > >
> > >
> > > Who is keeping track of this relationship?  
> >
> > Each device keeps track of:
> > - the parent (the coordinator it associated with, NULL if PAN
> >   coordinator)
> > - a list of devices (FFD or RFD) which successfully associated
> >  
> > > So we store pans which we
> > > found with a whole "subtree" attached to it?  
> >
> > This is different, we need basically three lists:
> > - the parent in the PAN
> > - the children (as in the logic of association) in the PAN
> > - the coordinators around which advertise their PAN with beacons (the
> >   PAN can be the same as ours, or different)
> >  
> > > btw: that sounds similar to me to what RPL is doing...,  
> >
> > I think RPL stands one level above in the OSI layers? Anyway, my
> > understanding (and this is really something which I grasped by reading
> > papers because the spec lacks a lot of information about it) is that:
> > - the list of PANs is mainly useful for our own initial association
> > - the list of immediate parent/children is to be used by the upper
> >   layer to create routes, but as in the 802.15.4 layer, we are not
> >   supposed to propagate this information besides giving it to the
> >   "next upper layer".
> >  
> 
> I am asking the question who stores that, because I don't think this
> should be stored in kernel space.

I think the kernel needs to keep track of the associated devices,
just to be able to give this information in an asynchronous manner to
the user ("next upper layer", whatever) and do very basic checks on
the user inputs to avoid confusing the neighboring devices. Note that
there is no way to "check" with mac commands if an association is
active or not. In practice I agree the kernel itself should not make any
other use of these information.

> A user space daemon will trigger the
> mac commands scan/assoc/deassoc/etc.

Yes

> (kernel job) and get the results of those commands and store it in
> however the user space daemon is handling it. This is from my point
> of view no kernel job, triggering the mac commands in a way that we
> can add all children information, parents, etc, whatever you need to
> fill information in mac commands. Yes, this is a kernel task.

So far I only focused on performing the mac commands and updating the
parent/children list, perhaps that should be improved to also give the
user the opportunity to add an association in the list that has been
performed "statically" (without mac commands, just by setting the PAN
ID to the right value).

> Also I heard that association with a coordinator will allocate in the
> pan a short address, the associated device (which triggered the
> association command) will then set the allocated short address by the
> coordinator, did you take a look into that?

Yes, the association requests contains a bit which means "please give
me a short address". The coordinator that receives the request should
then, if it decides to successfully associate with the device, get a
short address (randomly) and give it to the device by responding with an
association response which contains this address in the payload. The
associating device will then configure itself with this short address,
until it disassociates from the PAN. If the association request "give
me a short address" bit is unset, it means the device does not
want/supports short addressing, the coordinator should answer with the
specific value 0xfffe to notify the device that it will continue using
its extended address only as part of the communications happening
within the PAN. Typically, constrained RFDs might not accept short
addresses.

There is one caveat though, and this is not covered by the spec at all:
the coordinator has no knowledge of the surrounding devices out of its
own range, which could be part of the PAN through another coordinator.
In this case, if there is a short address conflict, there is no
procedure to detect nor correct the situation.

Thanks,
Miquèl

Powered by blists - more mailing lists