Re: [PATCH wpan-next 1/6] net: ieee802154: Drop coordinator interface type

[Alexander Aring <aahringo@redhat.com>]

Hi,

On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <miquel.raynal@bootlin.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"
and then there is "'device' is not associated". 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" ?

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

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

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

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

> > > - 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? So we store pans which we
found with a whole "subtree" attached to it?

btw: that sounds similar to me to what RPL is doing...,

- Alex