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

Commit Message

Miquel Raynal June 3, 2022, 6:21 p.m. UTC

The current enum is wrong. A device can either be an RFD, an RFD-RX, an
RFD-TX or an FFD. If it is an FFD, it can also be a coordinator. While
defining a node type might make sense from a strict software point of
view, opposing node and coordinator seems meaningless in the ieee
802.15.4 world. As this enumeration is not used anywhere, let's just
drop it. We will in a second time add a new "node type" enumeration
which apply only to nodes, and does differentiates the type of devices
mentioned above.

Signed-off-by: Miquel Raynal <[e-mail]>
---
 include/net/nl802154.h | 1 -
 1 file changed, 1 deletion(-)

Comments

Alexander Aring June 4, 2022, 2:01 a.m. UTC | #1

Hi,

On Fri, Jun 3, 2022 at 2:34 PM Miquel Raynal <[e-mail]> wrote:
>
> The current enum is wrong. A device can either be an RFD, an RFD-RX, an
> RFD-TX or an FFD. If it is an FFD, it can also be a coordinator. While
> defining a node type might make sense from a strict software point of
> view, opposing node and coordinator seems meaningless in the ieee
> 802.15.4 world. As this enumeration is not used anywhere, let's just
> drop it. We will in a second time add a new "node type" enumeration
> which apply only to nodes, and does differentiates the type of devices
> mentioned above.
>

First you cannot say if this is not used anywhere else. Second I have
a different opinion here that you cannot just "switch" the role from
RFD, FFD, whatever.
You are mixing things here with "role in the network" and what the
transceiver capability (RFD, FFD) is, which are two different things.

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.

- Alex

Miquel Raynal June 6, 2022, 3:43 p.m. UTC | #2

Hi Alexander,

[e-mail] wrote on Fri, 3 Jun 2022 22:01:38 -0400:

> Hi,
> 
> On Fri, Jun 3, 2022 at 2:34 PM Miquel Raynal <[e-mail]> wrote:
> >
> > The current enum is wrong. A device can either be an RFD, an RFD-RX, an
> > RFD-TX or an FFD. If it is an FFD, it can also be a coordinator. While
> > defining a node type might make sense from a strict software point of
> > view, opposing node and coordinator seems meaningless in the ieee
> > 802.15.4 world. As this enumeration is not used anywhere, let's just
> > drop it. We will in a second time add a new "node type" enumeration
> > which apply only to nodes, and does differentiates the type of devices
> > mentioned above.
> >  
> 
> First you cannot say if this is not used anywhere else.

Mmmh, that's tricky, I really don't see how that might be a
problem because there is literally nowhere in the kernel that uses this
type, besides ieee802154_setup_sdata() which would just BUG() if this
type was to be used. So I assumed it was safe to be removed.

> Second I have
> a different opinion here that you cannot just "switch" the role from
> RFD, FFD, whatever.

I agree with this, and that's why I don't understand this enum.

A device can either be a NODE (an active device) or a MONITOR (a
passive device) at a time. We can certainly switch from one to
another at run time.

A NODE can be either an RFD or an FFD. That is a static property which
cannot change.

However being a coordinator is just an additional property of a NODE
which is of type FFD, and this can change over time.

So I don't get what having a coordinator interface would bring. What
was the idea behind its introduction then?

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

Thanks,
Miquèl

Alexander Aring June 7, 2022, 3:04 a.m. UTC | #3

Hi,

On Mon, Jun 6, 2022 at 11:43 AM Miquel Raynal <[e-mail]> wrote:
>
> Hi Alexander,
>
> [e-mail] wrote on Fri, 3 Jun 2022 22:01:38 -0400:
>
> > Hi,
> >
> > On Fri, Jun 3, 2022 at 2:34 PM Miquel Raynal <[e-mail]> wrote:
> > >
> > > The current enum is wrong. A device can either be an RFD, an RFD-RX, an
> > > RFD-TX or an FFD. If it is an FFD, it can also be a coordinator. While
> > > defining a node type might make sense from a strict software point of
> > > view, opposing node and coordinator seems meaningless in the ieee
> > > 802.15.4 world. As this enumeration is not used anywhere, let's just
> > > drop it. We will in a second time add a new "node type" enumeration
> > > which apply only to nodes, and does differentiates the type of devices
> > > mentioned above.
> > >
> >
> > First you cannot say if this is not used anywhere else.
>
> Mmmh, that's tricky, I really don't see how that might be a
> problem because there is literally nowhere in the kernel that uses this
> type, besides ieee802154_setup_sdata() which would just BUG() if this
> type was to be used. So I assumed it was safe to be removed.
>

this header is somehow half uapi where we copy it into some other
software e.g. wpan-tools as you noticed.

> > Second I have
> > a different opinion here that you cannot just "switch" the role from
> > RFD, FFD, whatever.
>
> I agree with this, and that's why I don't understand this enum.
>
> A device can either be a NODE (an active device) or a MONITOR (a
> passive device) at a time. We can certainly switch from one to
> another at run time.
>
> A NODE can be either an RFD or an FFD. That is a static property which
> cannot change.
>
> However being a coordinator is just an additional property of a NODE
> which is of type FFD, and this can change over time.
>
> So I don't get what having a coordinator interface would bring. What
> was the idea behind its introduction then?
>

There exists arguments which I have in my mind right now:

1. frame parsing/address filter (which is somehow missing in your patches)

The parsing of frames is different from other types (just as monitor
interfaces). You will notice that setting up the address filter will
require a parameter if coordinator or not. Changing the address
filterung during runtime of an interface is somehow _not_ supported.
The reason is that the datasheets tell you to first set up an address
filter and then switch into receiving mode. Changing the address
filter during receive mode (start()/stop()) is not a specified
behaviour. Due to bus communication it also cannot be done atomically.
This might be avoidable but is a pain to synchronize if you really
depend on hw address filtering which we might do in future. It should
end in a different receiving path e.g. node_rx/monitor_rx.

2. HardMAC transceivers

The add_interface() callback will be directly forwarded to the driver
and the driver will during the lifetime of this interface act as a
coordinator and not a mixed mode which can be disabled and enabled
anytime. I am not even sure if this can ever be handled in such a way
from hardmac transceivers, it might depend on the transceiver
interface but we should assume some strict "static" handling. Static
handling means here that the transceiver is unable to switch from
coordinator and vice versa after some initialization state.

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.

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

- Alex

Miquel Raynal June 7, 2022, 4:16 p.m. UTC | #4

Hi Alex,

[e-mail] wrote on Mon, 6 Jun 2022 23:04:06 -0400:

> Hi,
> 
> On Mon, Jun 6, 2022 at 11:43 AM Miquel Raynal <[e-mail]> wrote:
> >
> > Hi Alexander,
> >
> > [e-mail] wrote on Fri, 3 Jun 2022 22:01:38 -0400:
> >  
> > > Hi,
> > >
> > > On Fri, Jun 3, 2022 at 2:34 PM Miquel Raynal <[e-mail]> wrote:  
> > > >
> > > > The current enum is wrong. A device can either be an RFD, an RFD-RX, an
> > > > RFD-TX or an FFD. If it is an FFD, it can also be a coordinator. While
> > > > defining a node type might make sense from a strict software point of
> > > > view, opposing node and coordinator seems meaningless in the ieee
> > > > 802.15.4 world. As this enumeration is not used anywhere, let's just
> > > > drop it. We will in a second time add a new "node type" enumeration
> > > > which apply only to nodes, and does differentiates the type of devices
> > > > mentioned above.
> > > >  
> > >
> > > First you cannot say if this is not used anywhere else.  
> >
> > Mmmh, that's tricky, I really don't see how that might be a
> > problem because there is literally nowhere in the kernel that uses this
> > type, besides ieee802154_setup_sdata() which would just BUG() if this
> > type was to be used. So I assumed it was safe to be removed.
> >  
> 
> this header is somehow half uapi where we copy it into some other
> software e.g. wpan-tools as you noticed.
> 
> > > Second I have
> > > a different opinion here that you cannot just "switch" the role from
> > > RFD, FFD, whatever.  
> >
> > I agree with this, and that's why I don't understand this enum.
> >
> > A device can either be a NODE (an active device) or a MONITOR (a
> > passive device) at a time. We can certainly switch from one to
> > another at run time.
> >
> > A NODE can be either an RFD or an FFD. That is a static property which
> > cannot change.
> >
> > However being a coordinator is just an additional property of a NODE
> > which is of type FFD, and this can change over time.
> >
> > So I don't get what having a coordinator interface would bring. What
> > was the idea behind its introduction then?
> >  
> 
> There exists arguments which I have in my mind right now:
> 
> 1. frame parsing/address filter (which is somehow missing in your patches)
> 
> The parsing of frames is different from other types (just as monitor
> interfaces). You will notice that setting up the address filter will
> require a parameter if coordinator or not.

I think this is something that I completely missed until now, can you
point me to where/how this is expected to be done? I don't see anything
wpan specific filtering implementation. What is expected on this area
and is there code that I missed already?

> Changing the address
> filterung during runtime of an interface is somehow _not_ supported.
> The reason is that the datasheets tell you to first set up an address
> filter and then switch into receiving mode. Changing the address
> filter during receive mode (start()/stop()) is not a specified
> behaviour. Due to bus communication it also cannot be done atomically.
> This might be avoidable but is a pain to synchronize if you really
> depend on hw address filtering which we might do in future. It should
> end in a different receiving path e.g. node_rx/monitor_rx.

Got it.

> 
> 2. HardMAC transceivers
> 
> The add_interface() callback will be directly forwarded to the driver
> and the driver will during the lifetime of this interface act as a
> coordinator and not a mixed mode which can be disabled and enabled
> anytime. I am not even sure if this can ever be handled in such a way
> from hardmac transceivers, it might depend on the transceiver
> interface but we should assume some strict "static" handling. Static
> handling means here that the transceiver is unable to switch from
> coordinator and vice versa after some initialization state.

Okay. I just completely missed the "interface add" command. So your
advice is to treat the "PAN coordinator" property as a static property
for a given interface, which seems reasonable.

For now I will assume the same treatment when adding the interface is
required compared to a NODE, but if something comes to your mind,
please let me know.

By the way, is there a mechanism limiting the number of interfaces on a
device? Should we prevent the introduction of a coordinator iface if
there is a node iface active?

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

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

Thanks,
Miquèl

Miquel Raynal June 8, 2022, 1:47 p.m. UTC | #5

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.

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?

Thanks,
Miquèl

Miquel Raynal June 8, 2022, 2:37 p.m. UTC | #6

[e-mail] 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?

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

Thanks,
Miquèl

Alexander Aring June 9, 2022, 1:42 a.m. UTC | #7

Hi,

On Tue, Jun 7, 2022 at 12:16 PM Miquel Raynal <[e-mail]> wrote:
>
> Hi Alex,
>
> [e-mail] wrote on Mon, 6 Jun 2022 23:04:06 -0400:
>
> > Hi,
> >
> > On Mon, Jun 6, 2022 at 11:43 AM Miquel Raynal <[e-mail]> wrote:
> > >
> > > Hi Alexander,
> > >
> > > [e-mail] wrote on Fri, 3 Jun 2022 22:01:38 -0400:
> > >
> > > > Hi,
> > > >
> > > > On Fri, Jun 3, 2022 at 2:34 PM Miquel Raynal <[e-mail]> wrote:
> > > > >
> > > > > The current enum is wrong. A device can either be an RFD, an RFD-RX, an
> > > > > RFD-TX or an FFD. If it is an FFD, it can also be a coordinator. While
> > > > > defining a node type might make sense from a strict software point of
> > > > > view, opposing node and coordinator seems meaningless in the ieee
> > > > > 802.15.4 world. As this enumeration is not used anywhere, let's just
> > > > > drop it. We will in a second time add a new "node type" enumeration
> > > > > which apply only to nodes, and does differentiates the type of devices
> > > > > mentioned above.
> > > > >
> > > >
> > > > First you cannot say if this is not used anywhere else.
> > >
> > > Mmmh, that's tricky, I really don't see how that might be a
> > > problem because there is literally nowhere in the kernel that uses this
> > > type, besides ieee802154_setup_sdata() which would just BUG() if this
> > > type was to be used. So I assumed it was safe to be removed.
> > >
> >
> > this header is somehow half uapi where we copy it into some other
> > software e.g. wpan-tools as you noticed.
> >
> > > > Second I have
> > > > a different opinion here that you cannot just "switch" the role from
> > > > RFD, FFD, whatever.
> > >
> > > I agree with this, and that's why I don't understand this enum.
> > >
> > > A device can either be a NODE (an active device) or a MONITOR (a
> > > passive device) at a time. We can certainly switch from one to
> > > another at run time.
> > >
> > > A NODE can be either an RFD or an FFD. That is a static property which
> > > cannot change.
> > >
> > > However being a coordinator is just an additional property of a NODE
> > > which is of type FFD, and this can change over time.
> > >
> > > So I don't get what having a coordinator interface would bring. What
> > > was the idea behind its introduction then?
> > >
> >
> > There exists arguments which I have in my mind right now:
> >
> > 1. frame parsing/address filter (which is somehow missing in your patches)
> >
> > The parsing of frames is different from other types (just as monitor
> > interfaces). You will notice that setting up the address filter will
> > require a parameter if coordinator or not.
>
> I think this is something that I completely missed until now, can you
> point me to where/how this is expected to be done? I don't see anything
> wpan specific filtering implementation. What is expected on this area
> and is there code that I missed already?
>

https://elixir.bootlin.com/linux/v5.19-rc1/source/net/mac802154/rx.c#L284

> > Changing the address
> > filterung during runtime of an interface is somehow _not_ supported.
> > The reason is that the datasheets tell you to first set up an address
> > filter and then switch into receiving mode. Changing the address
> > filter during receive mode (start()/stop()) is not a specified
> > behaviour. Due to bus communication it also cannot be done atomically.
> > This might be avoidable but is a pain to synchronize if you really
> > depend on hw address filtering which we might do in future. It should
> > end in a different receiving path e.g. node_rx/monitor_rx.
>
> Got it.
>

I had some thoughts about this as well when going to promiscuous mode
while in "receiving mode"... this is "normally" not supported...

> >
> > 2. HardMAC transceivers
> >
> > The add_interface() callback will be directly forwarded to the driver
> > and the driver will during the lifetime of this interface act as a
> > coordinator and not a mixed mode which can be disabled and enabled
> > anytime. I am not even sure if this can ever be handled in such a way
> > from hardmac transceivers, it might depend on the transceiver
> > interface but we should assume some strict "static" handling. Static
> > handling means here that the transceiver is unable to switch from
> > coordinator and vice versa after some initialization state.
>
> Okay. I just completely missed the "interface add" command. So your
> advice is to treat the "PAN coordinator" property as a static property
> for a given interface, which seems reasonable.
>
> For now I will assume the same treatment when adding the interface is
> required compared to a NODE, but if something comes to your mind,
> please let me know.
>
> By the way, is there a mechanism limiting the number of interfaces on a
> device? Should we prevent the introduction of a coordinator iface if
> there is a node iface active?
>

such a mechanism already exists, look at the code when trying to ifup
an interface in mac802154. You cannot simply have a monitor and node
up at the same time. Hardware could have multiple address filters and
run multiple mac stack instances on one phy, which is in my opinion
not different than macvlan and in wireless running multiple access
points on the same phy.

> > 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.
>
> > > > 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 think we need to figure this out...

- Alex

Alexander Aring June 9, 2022, 1:56 a.m. UTC | #8

Hi,

On Wed, Jun 8, 2022 at 9:47 AM Miquel Raynal <[e-mail]> wrote:
>
> 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.
>

I think it depends what exactly the difference is. So far I see for
address filtering it should be the same. Maybe this is an interface
option then?

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

What does it mean "algorithm is beyond the spec" - build your own?

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

When the hardware does not support it, it should be forbidden. As most
transceivers have only one address filter it should be forbidden
then... but there exists a way to indeed have such a setup (which you
probably don't need to think about). It's better to forbid something
now, with the possibility later allowing it. So it should not break
any existing behaviour.

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

I think this can be done all with some "fallback strategies" (build
your own) if it's not given as a parameter.

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

I thought the spec said "or otherwise"? That means if nothing can be
found, create one?

- Alex

Alexander Aring June 9, 2022, 2:06 a.m. UTC | #9

Hi,

On Wed, Jun 8, 2022 at 10:37 AM Miquel Raynal <[e-mail]> wrote:
>
>
> [e-mail] 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?

- Alex

Alexander Aring June 9, 2022, 2:23 a.m. UTC | #10

Hi,

On Wed, Jun 8, 2022 at 10:06 PM Alexander Aring <[e-mail]> wrote:
>
> Hi,
>
> On Wed, Jun 8, 2022 at 10:37 AM Miquel Raynal <[e-mail]> wrote:
> >
> >
> > [e-mail] 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

Miquel Raynal June 9, 2022, 2:42 p.m. UTC | #11

Hi Alex,

> > > > > Second I have
> > > > > a different opinion here that you cannot just "switch" the role from
> > > > > RFD, FFD, whatever.  
> > > >
> > > > I agree with this, and that's why I don't understand this enum.
> > > >
> > > > A device can either be a NODE (an active device) or a MONITOR (a
> > > > passive device) at a time. We can certainly switch from one to
> > > > another at run time.
> > > >
> > > > A NODE can be either an RFD or an FFD. That is a static property which
> > > > cannot change.
> > > >
> > > > However being a coordinator is just an additional property of a NODE
> > > > which is of type FFD, and this can change over time.
> > > >
> > > > So I don't get what having a coordinator interface would bring. What
> > > > was the idea behind its introduction then?
> > > >  
> > >
> > > There exists arguments which I have in my mind right now:
> > >
> > > 1. frame parsing/address filter (which is somehow missing in your patches)
> > >
> > > The parsing of frames is different from other types (just as monitor
> > > interfaces). You will notice that setting up the address filter will
> > > require a parameter if coordinator or not.  
> >
> > I think this is something that I completely missed until now, can you
> > point me to where/how this is expected to be done? I don't see anything
> > wpan specific filtering implementation. What is expected on this area
> > and is there code that I missed already?
> >  
> 
> https://elixir.bootlin.com/linux/v5.19-rc1/source/net/mac802154/rx.c#L284

Oh okay now I get what you mean. Indeed, I had to look into this
function to allow coordinators to receive packets with the IFACE_COORD
implementation, but so far the filtering is "the same" as for a node.
We can improve that later if needed.
 
> > > Changing the address
> > > filterung during runtime of an interface is somehow _not_ supported.
> > > The reason is that the datasheets tell you to first set up an address
> > > filter and then switch into receiving mode. Changing the address
> > > filter during receive mode (start()/stop()) is not a specified
> > > behaviour. Due to bus communication it also cannot be done atomically.
> > > This might be avoidable but is a pain to synchronize if you really
> > > depend on hw address filtering which we might do in future. It should
> > > end in a different receiving path e.g. node_rx/monitor_rx.  
> >
> > Got it.
> >  
> 
> I had some thoughts about this as well when going to promiscuous mode
> while in "receiving mode"... this is "normally" not supported...
> 
> > >
> > > 2. HardMAC transceivers
> > >
> > > The add_interface() callback will be directly forwarded to the driver
> > > and the driver will during the lifetime of this interface act as a
> > > coordinator and not a mixed mode which can be disabled and enabled
> > > anytime. I am not even sure if this can ever be handled in such a way
> > > from hardmac transceivers, it might depend on the transceiver
> > > interface but we should assume some strict "static" handling. Static
> > > handling means here that the transceiver is unable to switch from
> > > coordinator and vice versa after some initialization state.  
> >
> > Okay. I just completely missed the "interface add" command. So your
> > advice is to treat the "PAN coordinator" property as a static property
> > for a given interface, which seems reasonable.
> >
> > For now I will assume the same treatment when adding the interface is
> > required compared to a NODE, but if something comes to your mind,
> > please let me know.
> >
> > By the way, is there a mechanism limiting the number of interfaces on a
> > device? Should we prevent the introduction of a coordinator iface if
> > there is a node iface active?
> >  
> 
> such a mechanism already exists, look at the code when trying to ifup
> an interface in mac802154. You cannot simply have a monitor and node
> up at the same time. Hardware could have multiple address filters and
> run multiple mac stack instances on one phy, which is in my opinion
> not different than macvlan and in wireless running multiple access
> points on the same phy.

Oh nice, I didn't pay enough attention to figure out that this was
executed during ifup. So I already changed that code to refuse two node
*and* coordinators to be up at the same time, we should be on the safe
side.

Thanks,
Miquèl

Miquel Raynal June 9, 2022, 3:43 p.m. UTC | #12

Hi Alex,

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

I didn't find anything. I suppose we can ask for that parameter at PAN
creation, but otherwise I'll keep a backward compatible value: 15,
which means that the PAN is not beacon enabled (like today, basically).

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

Actually this is none of the 802.15.4 MAC layer business. I believe
this is the upper layer duty to make this interoperability work,
namely, 6lowpan?

Thanks,
Miquèl

Miquel Raynal June 9, 2022, 3:52 p.m. UTC | #13

Hi Alexander,

[e-mail] wrote on Wed, 8 Jun 2022 21:56:53 -0400:

> Hi,
> 
> On Wed, Jun 8, 2022 at 9:47 AM Miquel Raynal <[e-mail]> wrote:
> >
> > 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.
> >  
> 
> I think it depends what exactly the difference is. So far I see for
> address filtering it should be the same. Maybe this is an interface
> option then?

The difference is that the PAN coordinator can decide to eg. refuse an
association, while the other coordinators, are just FFDs with no
specific decision making capability wrt the PAN itself, but have some
routing capabilities available for the upper layers.

The most I look into this, the less likely it is that the Linux stack
will drive an RFD. Do you think it's worth supporting them? Because if
we don't:
* NODE == FFD which acts as coordinator
* COORD == FFD which acts as the PAN coordinator

> > > > > > 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.
> >  
> 
> What does it mean "algorithm is beyond the spec" - build your own?

This is really what is in the spec, I suppose it means "do what you
want in your use case".

What I have in mind: when a device is powered on and detects two PANs,
well, it can join whichever it wants, but perhaps we should make the
decision based on the LQI information we have (the closer the better).

> > * 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.
> >
> > 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?
> >  
> 
> When the hardware does not support it, it should be forbidden. As most
> transceivers have only one address filter it should be forbidden
> then... but there exists a way to indeed have such a setup (which you
> probably don't need to think about). It's better to forbid something
> now, with the possibility later allowing it. So it should not break
> any existing behaviour.

Done, thanks to the pointer you gave in the other mail.

> 
> > - 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?
> >  
> 
> I think this can be done all with some "fallback strategies" (build
> your own) if it's not given as a parameter.

Ok, In case no PAN is found, and at creation no PAN ID is provided, we
can default to 0.

> > - 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?
> >  
> 
> I thought the spec said "or otherwise"? That means if nothing can be
> found, create one?

Ok, so we assume this is only at startup, fine. But then how to handle
the set_pan_id() call? I believe we can forbid any set_pan_id() command
to be run while the interface is up. That would ease the handling.
Unless I am missing something?

Thanks,
Miquèl

Alexander Aring June 11, 2022, 12:05 p.m. UTC | #14

Hi,

On Thu, Jun 9, 2022 at 11:44 AM Miquel Raynal <[e-mail]> wrote:
>
> Hi Alex,
>
> > > >
> > > >   - 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?
>
> I didn't find anything. I suppose we can ask for that parameter at PAN
> creation, but otherwise I'll keep a backward compatible value: 15,
> which means that the PAN is not beacon enabled (like today, basically).
>

I hope it is not necessary to answer this question, see below.

> > >
> > > >   - 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).
>
> Actually this is none of the 802.15.4 MAC layer business. I believe
> this is the upper layer duty to make this interoperability work,
> namely, 6lowpan?

I am not sure if I understand your answer, I meant that if
"coordinator" or "PAN coordinator" depends on whatever, if somebody is
running a "coordinator" software in the background on top of a coord
interface.
The kernel offers the functionality for scan/assoc/etc. (offers link
quality, etc. _statistics_ and not _heuristic_) which will be used by
this software to whatever the user defines to realize this behaviour
as it is user specific.

Sure linux-wpan, should then provide at least a standard piece of
software for it.

This has in my opinion nothing to do with 6lowpan.

- Alex

Miquel Raynal June 15, 2022, 9:15 a.m. UTC | #15

Hi Alexander,

[e-mail] wrote on Sat, 11 Jun 2022 08:05:31 -0400:

> Hi,
> 
> On Thu, Jun 9, 2022 at 11:44 AM Miquel Raynal <[e-mail]> wrote:
> >
> > Hi Alex,
> >  
> > > > >
> > > > >   - 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?  
> >
> > I didn't find anything. I suppose we can ask for that parameter at PAN
> > creation, but otherwise I'll keep a backward compatible value: 15,
> > which means that the PAN is not beacon enabled (like today, basically).
> >  
> 
> I hope it is not necessary to answer this question, see below.
> 
> > > >  
> > > > >   - 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).  
> >
> > Actually this is none of the 802.15.4 MAC layer business. I believe
> > this is the upper layer duty to make this interoperability work,
> > namely, 6lowpan?  
> 
> I am not sure if I understand your answer, I meant that if
> "coordinator" or "PAN coordinator" depends on whatever, if somebody is
> running a "coordinator" software in the background on top of a coord
> interface.
> The kernel offers the functionality for scan/assoc/etc. (offers link
> quality, etc. _statistics_ and not _heuristic_) which will be used by
> this software to whatever the user defines to realize this behaviour
> as it is user specific.

Yes.

> Sure linux-wpan, should then provide at least a standard piece of
> software for it.
> 
> This has in my opinion nothing to do with 6lowpan.

I was referring to the cluster topology routing logic. The routing
logic to reach a device in a PAN that is not directly reachable by the
PAN coordinator is the responsibility of the layer 3 in the OSI model,
so I believe it's either 6lowpan's duty or even above.

Thanks,
Miquèl

Miquel Raynal June 17, 2022, 3:12 p.m. UTC | #16

Hi Alex,

[e-mail] wrote on Sat, 11 Jun 2022 08:23:41 -0400:

> Hi,
> 
> On Thu, Jun 9, 2022 at 11:52 AM Miquel Raynal <[e-mail]> wrote:
> >
> > Hi Alexander,
> >
> > [e-mail] wrote on Wed, 8 Jun 2022 21:56:53 -0400:
> >  
> > > Hi,
> > >
> > > On Wed, Jun 8, 2022 at 9:47 AM Miquel Raynal <[e-mail]> wrote:  
> > > >
> > > > 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.
> > > >  
> > >
> > > I think it depends what exactly the difference is. So far I see for
> > > address filtering it should be the same. Maybe this is an interface
> > > option then?  
> >
> > The difference is that the PAN coordinator can decide to eg. refuse an
> > association, while the other coordinators, are just FFDs with no
> > specific decision making capability wrt the PAN itself, but have some
> > routing capabilities available for the upper layers.
> >  
> 
> As I said, if there is a behaviour "it can do xxx, but the spec
> doesn't give more information about it" this smells for me like things
> moving into the user space. This can also be done e.g. by a filtering
> mechanism, _just_ the user will configure how this filtering will look
> like.
> 
> > The most I look into this, the less likely it is that the Linux stack
> > will drive an RFD. Do you think it's worth supporting them? Because if
> > we don't:
> > * NODE == FFD which acts as coordinator
> > * COORD == FFD which acts as the PAN coordinator
> >  
> 
> I thought that this is a kind of "transceiver type capability " e.g. I
> can imagine if it's only a "RFD" transceiver then you would be e.g.
> not able to set the address filter to coordinator capability. However
> I think that will never happen for a SoftMAC transceiver because why
> not adding a little bit silicon to provide that? People also can
> always have a co-processor and run the transceiver in promiscuous
> mode. E.g. atusb (which makes this transceiver poweful, because we
> have control over the firmware).
> 
> For me node != coord, because the address filtering is different. As I
> mentioned in another mail "coordinator" vs "PAN coordinator" as
> described is what the user is doing here on top of it.
> 
> > > > > > > > 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.
> > > >  
> > >
> > > What does it mean "algorithm is beyond the spec" - build your own?  
> >
> > This is really what is in the spec, I suppose it means "do what you
> > want in your use case".
> >
> > What I have in mind: when a device is powered on and detects two PANs,
> > well, it can join whichever it wants, but perhaps we should make the
> > decision based on the LQI information we have (the closer the better).
> >  
> 
> As I said in the other mail, this smells more and more for me to move
> this handling to user space. The kernel therefore supports operations
> to trigger the necessary steps (scan/assoc/etc.)
> 
> > > > * 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.
> > > >
> > > > 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?
> > > >  
> > >
> > > When the hardware does not support it, it should be forbidden. As most
> > > transceivers have only one address filter it should be forbidden
> > > then... but there exists a way to indeed have such a setup (which you
> > > probably don't need to think about). It's better to forbid something
> > > now, with the possibility later allowing it. So it should not break
> > > any existing behaviour.  
> >
> > Done, thanks to the pointer you gave in the other mail.
> >  
> > >  
> > > > - 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?
> > > >  
> > >
> > > I think this can be done all with some "fallback strategies" (build
> > > your own) if it's not given as a parameter.  
> >
> > Ok, In case no PAN is found, and at creation no PAN ID is provided, we
> > can default to 0.
> >  
> 
> See me for other mails. (user space job)
> 
> > > > - 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?
> > > >  
> > >
> > > I thought the spec said "or otherwise"? That means if nothing can be
> > > found, create one?  
> >
> > Ok, so we assume this is only at startup, fine. But then how to handle
> > the set_pan_id() call? I believe we can forbid any set_pan_id() command
> > to be run while the interface is up. That would ease the handling.
> > Unless I am missing something?
> >  
> 
> See my other mails (user space job).

Ok then, I'll go with the following constraints in mind:

SCAN (passive/active) (all devices)
- All devices are allowed to perform scans.
- The user decides when a scan must be performed, there is no
  limitation on when to do a scan (but the interface must be up for
  physical reasons).
PAN ID
- The user is responsible to set the PAN ID.
- Like several other parameters, the PAN ID can only be changed if the
  iface is down. Which means the user might need to do:
	link up > scan > link down > set params > link up 
BEACON
- Coordinator interfaces only can send beacons.
- Beacons can only be sent when part of a PAN (PAN ID != 0xffff).
- The choice of the beacon interval is up to the user, at any moment.
OTHER PARAMETERS
- The choice of the channel (page, etc) is free until the device is
  associated to another, then it becomes fixed.

ASSOCIATION (to be done)
- Device association/disassociation procedure is requested by the
  user.
- Accepting new associations is up to the user (coordinator only).
- If the device has no parent (was not associated to any device) it is
  PAN coordinator and has additional rights regarding associations.

Thanks,
Miquèl

Alexander Aring June 20, 2022, 12:13 a.m. UTC | #17

Hi,

On Fri, Jun 17, 2022 at 11:13 AM Miquel Raynal
<[e-mail]> wrote:
>
> Hi Alex,
>
> [e-mail] wrote on Sat, 11 Jun 2022 08:23:41 -0400:
>
> > Hi,
> >
> > On Thu, Jun 9, 2022 at 11:52 AM Miquel Raynal <[e-mail]> wrote:
> > >
> > > Hi Alexander,
> > >
> > > [e-mail] wrote on Wed, 8 Jun 2022 21:56:53 -0400:
> > >
> > > > Hi,
> > > >
> > > > On Wed, Jun 8, 2022 at 9:47 AM Miquel Raynal <[e-mail]> wrote:
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > I think it depends what exactly the difference is. So far I see for
> > > > address filtering it should be the same. Maybe this is an interface
> > > > option then?
> > >
> > > The difference is that the PAN coordinator can decide to eg. refuse an
> > > association, while the other coordinators, are just FFDs with no
> > > specific decision making capability wrt the PAN itself, but have some
> > > routing capabilities available for the upper layers.
> > >
> >
> > As I said, if there is a behaviour "it can do xxx, but the spec
> > doesn't give more information about it" this smells for me like things
> > moving into the user space. This can also be done e.g. by a filtering
> > mechanism, _just_ the user will configure how this filtering will look
> > like.
> >
> > > The most I look into this, the less likely it is that the Linux stack
> > > will drive an RFD. Do you think it's worth supporting them? Because if
> > > we don't:
> > > * NODE == FFD which acts as coordinator
> > > * COORD == FFD which acts as the PAN coordinator
> > >
> >
> > I thought that this is a kind of "transceiver type capability " e.g. I
> > can imagine if it's only a "RFD" transceiver then you would be e.g.
> > not able to set the address filter to coordinator capability. However
> > I think that will never happen for a SoftMAC transceiver because why
> > not adding a little bit silicon to provide that? People also can
> > always have a co-processor and run the transceiver in promiscuous
> > mode. E.g. atusb (which makes this transceiver poweful, because we
> > have control over the firmware).
> >
> > For me node != coord, because the address filtering is different. As I
> > mentioned in another mail "coordinator" vs "PAN coordinator" as
> > described is what the user is doing here on top of it.
> >
> > > > > > > > > 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.
> > > > >
> > > >
> > > > What does it mean "algorithm is beyond the spec" - build your own?
> > >
> > > This is really what is in the spec, I suppose it means "do what you
> > > want in your use case".
> > >
> > > What I have in mind: when a device is powered on and detects two PANs,
> > > well, it can join whichever it wants, but perhaps we should make the
> > > decision based on the LQI information we have (the closer the better).
> > >
> >
> > As I said in the other mail, this smells more and more for me to move
> > this handling to user space. The kernel therefore supports operations
> > to trigger the necessary steps (scan/assoc/etc.)
> >
> > > > > * 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.
> > > > >
> > > > > 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?
> > > > >
> > > >
> > > > When the hardware does not support it, it should be forbidden. As most
> > > > transceivers have only one address filter it should be forbidden
> > > > then... but there exists a way to indeed have such a setup (which you
> > > > probably don't need to think about). It's better to forbid something
> > > > now, with the possibility later allowing it. So it should not break
> > > > any existing behaviour.
> > >
> > > Done, thanks to the pointer you gave in the other mail.
> > >
> > > >
> > > > > - 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?
> > > > >
> > > >
> > > > I think this can be done all with some "fallback strategies" (build
> > > > your own) if it's not given as a parameter.
> > >
> > > Ok, In case no PAN is found, and at creation no PAN ID is provided, we
> > > can default to 0.
> > >
> >
> > See me for other mails. (user space job)
> >
> > > > > - 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?
> > > > >
> > > >
> > > > I thought the spec said "or otherwise"? That means if nothing can be
> > > > found, create one?
> > >
> > > Ok, so we assume this is only at startup, fine. But then how to handle
> > > the set_pan_id() call? I believe we can forbid any set_pan_id() command
> > > to be run while the interface is up. That would ease the handling.
> > > Unless I am missing something?
> > >
> >
> > See my other mails (user space job).
>
> Ok then, I'll go with the following constraints in mind:
>
> SCAN (passive/active) (all devices)
> - All devices are allowed to perform scans.
> - The user decides when a scan must be performed, there is no
>   limitation on when to do a scan (but the interface must be up for
>   physical reasons).

Yes, I think it should not have anything to do with interface
limitation.... it needs to have an operating phy. However I can say
more to this when I see code (but please don't provide me with any
github repository, I mean here on the mailing list and not a more than
15 patches stack, Thanks.) You probably want to say on an user level
"run scan for iface $FOO" but this is just to make it simpler.

> PAN ID
> - The user is responsible to set the PAN ID.

This is currently the case and I don't see a reason to change it.

> - Like several other parameters, the PAN ID can only be changed if the
>   iface is down. Which means the user might need to do:
>         link up > scan > link down > set params > link up

Yes, changing this behaviour will break other things.

> BEACON
> - Coordinator interfaces only can send beacons.

okay.

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

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

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

> - Accepting new associations is up to the user (coordinator only).

Again implementation details how this should be realized.

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

- Alex

Miquel Raynal June 20, 2022, 9:19 a.m. UTC | #18

Hi Alexander,

[e-mail] wrote on Sun, 19 Jun 2022 20:13:08 -0400:

> Hi,
> 
> On Fri, Jun 17, 2022 at 11:13 AM Miquel Raynal
> <[e-mail]> wrote:
> >
> > Hi Alex,
> >
> > [e-mail] wrote on Sat, 11 Jun 2022 08:23:41 -0400:
> >  
> > > Hi,
> > >
> > > On Thu, Jun 9, 2022 at 11:52 AM Miquel Raynal <[e-mail]> wrote:  
> > > >
> > > > Hi Alexander,
> > > >
> > > > [e-mail] wrote on Wed, 8 Jun 2022 21:56:53 -0400:
> > > >  
> > > > > Hi,
> > > > >
> > > > > On Wed, Jun 8, 2022 at 9:47 AM Miquel Raynal <[e-mail]> wrote:  
> > > > > >
> > > > > > 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.
> > > > > >  
> > > > >
> > > > > I think it depends what exactly the difference is. So far I see for
> > > > > address filtering it should be the same. Maybe this is an interface
> > > > > option then?  
> > > >
> > > > The difference is that the PAN coordinator can decide to eg. refuse an
> > > > association, while the other coordinators, are just FFDs with no
> > > > specific decision making capability wrt the PAN itself, but have some
> > > > routing capabilities available for the upper layers.
> > > >  
> > >
> > > As I said, if there is a behaviour "it can do xxx, but the spec
> > > doesn't give more information about it" this smells for me like things
> > > moving into the user space. This can also be done e.g. by a filtering
> > > mechanism, _just_ the user will configure how this filtering will look
> > > like.
> > >  
> > > > The most I look into this, the less likely it is that the Linux stack
> > > > will drive an RFD. Do you think it's worth supporting them? Because if
> > > > we don't:
> > > > * NODE == FFD which acts as coordinator
> > > > * COORD == FFD which acts as the PAN coordinator
> > > >  
> > >
> > > I thought that this is a kind of "transceiver type capability " e.g. I
> > > can imagine if it's only a "RFD" transceiver then you would be e.g.
> > > not able to set the address filter to coordinator capability. However
> > > I think that will never happen for a SoftMAC transceiver because why
> > > not adding a little bit silicon to provide that? People also can
> > > always have a co-processor and run the transceiver in promiscuous
> > > mode. E.g. atusb (which makes this transceiver poweful, because we
> > > have control over the firmware).
> > >
> > > For me node != coord, because the address filtering is different. As I
> > > mentioned in another mail "coordinator" vs "PAN coordinator" as
> > > described is what the user is doing here on top of it.
> > >  
> > > > > > > > > > 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.
> > > > > >  
> > > > >
> > > > > What does it mean "algorithm is beyond the spec" - build your own?  
> > > >
> > > > This is really what is in the spec, I suppose it means "do what you
> > > > want in your use case".
> > > >
> > > > What I have in mind: when a device is powered on and detects two PANs,
> > > > well, it can join whichever it wants, but perhaps we should make the
> > > > decision based on the LQI information we have (the closer the better).
> > > >  
> > >
> > > As I said in the other mail, this smells more and more for me to move
> > > this handling to user space. The kernel therefore supports operations
> > > to trigger the necessary steps (scan/assoc/etc.)
> > >  
> > > > > > * 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.
> > > > > >
> > > > > > 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?
> > > > > >  
> > > > >
> > > > > When the hardware does not support it, it should be forbidden. As most
> > > > > transceivers have only one address filter it should be forbidden
> > > > > then... but there exists a way to indeed have such a setup (which you
> > > > > probably don't need to think about). It's better to forbid something
> > > > > now, with the possibility later allowing it. So it should not break
> > > > > any existing behaviour.  
> > > >
> > > > Done, thanks to the pointer you gave in the other mail.
> > > >  
> > > > >  
> > > > > > - 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?
> > > > > >  
> > > > >
> > > > > I think this can be done all with some "fallback strategies" (build
> > > > > your own) if it's not given as a parameter.  
> > > >
> > > > Ok, In case no PAN is found, and at creation no PAN ID is provided, we
> > > > can default to 0.
> > > >  
> > >
> > > See me for other mails. (user space job)
> > >  
> > > > > > - 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?
> > > > > >  
> > > > >
> > > > > I thought the spec said "or otherwise"? That means if nothing can be
> > > > > found, create one?  
> > > >
> > > > Ok, so we assume this is only at startup, fine. But then how to handle
> > > > the set_pan_id() call? I believe we can forbid any set_pan_id() command
> > > > to be run while the interface is up. That would ease the handling.
> > > > Unless I am missing something?
> > > >  
> > >
> > > See my other mails (user space job).  
> >
> > Ok then, I'll go with the following constraints in mind:
> >
> > SCAN (passive/active) (all devices)
> > - All devices are allowed to perform scans.
> > - The user decides when a scan must be performed, there is no
> >   limitation on when to do a scan (but the interface must be up for
> >   physical reasons).  
> 
> Yes, I think it should not have anything to do with interface
> limitation.... it needs to have an operating phy.

Yes

> However I can say
> more to this when I see code (but please don't provide me with any
> github repository, I mean here on the mailing list and not a more than
> 15 patches stack, Thanks.) You probably want to say on an user level
> "run scan for iface $FOO" but this is just to make it simpler.
> 
> > PAN ID
> > - The user is responsible to set the PAN ID.  
> 
> This is currently the case and I don't see a reason to change it.
> 
> > - Like several other parameters, the PAN ID can only be changed if the
> >   iface is down. Which means the user might need to do:
> >         link up > scan > link down > set params > link up  
> 
> Yes, changing this behaviour will break other things.
> 
> > BEACON
> > - Coordinator interfaces only can send beacons.  
> 
> okay.
> 
> > - 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."

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

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

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

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

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

The sentence about the additional rights is wrong, however, the spec
does not state anything about it, it was a misinterpretation on my side.

Thanks,
Miquèl

Alexander Aring June 21, 2022, 1:54 a.m. UTC | #19

Hi,

On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <[e-mail]> 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

Miquel Raynal June 21, 2022, 6:27 a.m. UTC | #20

Hi Alexander,

[e-mail] wrote on Mon, 20 Jun 2022 21:54:33 -0400:

> Hi,
> 
> On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <[e-mail]> 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

Alexander Aring June 26, 2022, 1:36 a.m. UTC | #21

Hi,

On Tue, Jun 21, 2022 at 2:27 AM Miquel Raynal <[e-mail]> wrote:
>
> Hi Alexander,
>
> [e-mail] wrote on Mon, 20 Jun 2022 21:54:33 -0400:
>
> > Hi,
> >
> > On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <[e-mail]> 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

Miquel Raynal June 27, 2022, 8:17 a.m. UTC | #22

Hi Alexander,

[e-mail] wrote on Sat, 25 Jun 2022 21:36:05 -0400:

> Hi,
> 
> On Tue, Jun 21, 2022 at 2:27 AM Miquel Raynal <[e-mail]> wrote:
> >
> > Hi Alexander,
> >
> > [e-mail] wrote on Mon, 20 Jun 2022 21:54:33 -0400:
> >  
> > > Hi,
> > >
> > > On Mon, Jun 20, 2022 at 5:19 AM Miquel Raynal <[e-mail]> 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.

Yes, I am referring to the association procedure here, but I agree it
can be done "statically", that's how it's been done in Linux so far
anyway.

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

I think we are aligned on the terms.

"Coordinators are not supposed to send any beacon if they are not part
of a PAN." if you prefer. But then while your are not connected to any
network, can we really talk about coordinator? A coordinator, as you
rightfully said, is a living role, so talking about a coordinator that
is not "associated" does not really make sense. Hence the generic term
"device", which I stretched a bit towards "FFD" because RFDs cannot
become coordinators on the network.

Anyway, I think we mean the same thing :)

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

Absolutely

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

Yes

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

I think the kernel needs to keep track of the associated devices,
just to be able to give this information in an asynchronous manner to
the user ("next upper layer", whatever) and do very basic checks on
the user inputs to avoid confusing the neighboring devices. Note that
there is no way to "check" with mac commands if an association is
active or not. In practice I agree the kernel itself should not make any
other use of these information.

> A user space daemon will trigger the
> mac commands scan/assoc/deassoc/etc.

Yes

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

So far I only focused on performing the mac commands and updating the
parent/children list, perhaps that should be improved to also give the
user the opportunity to add an association in the list that has been
performed "statically" (without mac commands, just by setting the PAN
ID to the right value).

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

Yes, the association requests contains a bit which means "please give
me a short address". The coordinator that receives the request should
then, if it decides to successfully associate with the device, get a
short address (randomly) and give it to the device by responding with an
association response which contains this address in the payload. The
associating device will then configure itself with this short address,
until it disassociates from the PAN. If the association request "give
me a short address" bit is unset, it means the device does not
want/supports short addressing, the coordinator should answer with the
specific value 0xfffe to notify the device that it will continue using
its extended address only as part of the communications happening
within the PAN. Typically, constrained RFDs might not accept short
addresses.

There is one caveat though, and this is not covered by the spec at all:
the coordinator has no knowledge of the surrounding devices out of its
own range, which could be part of the PAN through another coordinator.
In this case, if there is a short address conflict, there is no
procedure to detect nor correct the situation.

Thanks,
Miquèl

Patch

diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 145acb8f2509..0f508aaae126 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -156,7 +156,6 @@  enum nl802154_iftype {
 
 	NL802154_IFTYPE_NODE = 0,
 	NL802154_IFTYPE_MONITOR,
-	NL802154_IFTYPE_COORD,
 
 	/* keep last */
 	NUM_NL802154_IFTYPES,