Message-ID: <20220621082714.78451ee0@xps-13>
Date:   Tue, 21 Jun 2022 08:27:14 +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 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".

FFDs are not supposed to send any beacon if they are not part of a PAN.

> 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

> > > > - 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.

> > - 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

> > > > - 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

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.
> 
> > > > - 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".

Thanks,
Miquèl

Powered by blists - more mailing lists