Hi, On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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
