Hi, On Wed, Jun 8, 2022 at 10:06 PM Alexander Aring <aahringo@xxxxxxxxxx> wrote: > > Hi, > > On Wed, Jun 8, 2022 at 10:37 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > > > miquel.raynal@xxxxxxxxxxx wrote on Wed, 8 Jun 2022 15:47:49 +0200: > > > > > Hi Alex, > > > > > > > > 3. coordinator (any $TYPE specific) userspace software > > > > > > > > > > May the main argument. Some coordinator specific user space daemon > > > > > does specific type handling (e.g. hostapd) maybe because some library > > > > > is required. It is a pain to deal with changing roles during the > > > > > lifetime of an interface and synchronize user space software with it. > > > > > We should keep in mind that some of those handlings will maybe be > > > > > moved to user space instead of doing it in the kernel. I am fine with > > > > > the solution now, but keep in mind to offer such a possibility. > > > > > > > > > > I think the above arguments are probably the same why wireless is > > > > > doing something similar and I would avoid running into issues or it's > > > > > really difficult to handle because you need to solve other Linux net > > > > > architecture handling at first. > > > > > > > > Yep. > > > > > > The spec makes a difference between "coordinator" and "PAN > > > coordinator", which one is the "coordinator" interface type supposed to > > > picture? I believe we are talking about being a "PAN coordinator", but > > > I want to be sure that we are aligned on the terms. > > > > > > > > > > You are mixing things here with "role in the network" and what > > > > > > > the transceiver capability (RFD, FFD) is, which are two > > > > > > > different things. > > > > > > > > > > > > I don't think I am, however maybe our vision differ on what an > > > > > > interface should be. > > > > > > > > > > > > > You should use those defines and the user needs to create a new > > > > > > > interface type and probably have a different extended address > > > > > > > to act as a coordinator. > > > > > > > > > > > > Can't we just simply switch from coordinator to !coordinator > > > > > > (that's what I currently implemented)? Why would we need the user > > > > > > to create a new interface type *and* to provide a new address? > > > > > > > > > > > > Note that these are real questions that I am asking myself. I'm > > > > > > fine adapting my implementation, as long as I get the main idea. > > > > > > > > > > > > > > > > See above. > > > > > > > > That's okay for me. I will adapt my implementation to use the > > > > interface thing. In the mean time additional details about what a > > > > coordinator interface should do differently (above question) is > > > > welcome because this is not something I am really comfortable with. > > > > > > I've updated the implementation to use the IFACE_COORD interface and it > > > works fine, besides one question below. > > > > > > Also, I read the spec once again (soon I'll sleep with it) and > > > actually what I extracted is that: > > > > > > * A FFD, when turned on, will perform a scan, then associate to any PAN > > > it found (algorithm is beyond the spec) or otherwise create a PAN ID > > > and start its own PAN. In both cases, it finishes its setup by > > > starting to send beacons. > > > > > > * A RFD will behave more or less the same, without the PAN creation > > > possibility of course. RFD-RX and RFD-TX are not required to support > > > any of that, I'll assume none of the scanning features is suitable > > > for them. > > > > Acutally, RFDs do not send beacons, AFAIU. > > > > > I have a couple of questions however: > > > > > > - Creating an interface (let's call it wpancoord) out of wpan0 means > > > that two interfaces can be used in different ways and one can use > > > wpan0 as a node while using wpancoord as a PAN coordinator. Is that > > > really allowed? How should we prevent this from happening? > > > > > > - Should the device always wait for the user(space) to provide the PAN > > > to associate to after the scan procedure right after the > > > add_interface()? (like an information that must be provided prior to > > > set the interface up?) > > > > > > - How does an orphan FFD should pick the PAN ID for a PAN creation? > > > Should we use a random number? Start from 0 upwards? Start from > > > 0xfffd downwards? Should the user always provide it? > > > > > > - Should an FFD be able to create its own PAN on demand? Shall we > > > allow to do that at the creation of the new interface? > > > > Additional questions: > > > > - How is chosen the beacon order? Should we have a default value? > > Should we default to 15 (not on a beacon enabled PAN)? Should we be > > able to update this value during the lifetime of the PAN? > > > > Is there no mib default value for this? > > > - The spec talks about the cluster topology, where a coordinator that > > just associated to a PAN starts emitting beacons, which may enable > > other devices in its range to ask to join the PAN (increased area > > coverage). But then, there is no information about how the newly > > added device should do to join the PAN coordinator which is anyway > > out of range to require the association, transmit data, etc. Any > > idea how this is supposed to work? > > > > I think we should maybe add a feature for this later if we don't know > how it is supposed to work or there are still open questions and first > introduce the manual setup. After that, maybe things will become > clearer and we can add support for this part. Is this okay? *I also think that this can be done in user space by a daemon by triggering netlink commands for scan/assoc/etc. (manual setup) and providing such functionality as mentioned by the spec (auto creation of pan, assoc with pan). Things which are unclear here are then moved to the user as the operations for scan/assoc/etc. will not be different or at least parameterized. The point here is that providing the minimum basic functionality should be done at first, then we can look at how to realize such handling (either in kernel or user space). - Alex
