Hi, On Tue, Jun 21, 2022 at 2:27 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hi Alexander, > > aahringo@xxxxxxxxxx wrote on Mon, 20 Jun 2022 21:54:33 -0400: > > > 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" > > 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. 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. > > 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. > > > > > - 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. > > > - 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. A user space daemon will trigger the mac commands scan/assoc/deassoc/etc. (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. 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? - Alex
