[PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Miquel Raynal]

Hello,
These three patches allow the creation of coordinator interfaces, which
were already defined without being usable. The idea behind is to use
them advertizing PANs through the beaconing feature.

Changes since v1:
* Addition of patches 1 and 2.
* Improved the commit message of patch 3.
* Rebased.
* Minor fixes.

Miquel Raynal (3):
  mac802154: Move an skb free within the rx path
  mac802154: Clarify an expression
  mac802154: Allow the creation of coordinator interfaces

 net/mac802154/iface.c | 15 ++++++++-------
 net/mac802154/main.c  |  2 +-
 net/mac802154/rx.c    | 24 +++++++++++-------------
 3 files changed, 20 insertions(+), 21 deletions(-)

-- 
2.34.1

[PATCH wpan-next v2 1/3] mac802154: Move an skb free within the rx path

[Miquel Raynal]

It may appear clearer to free the skb at the end of the path rather than
in the middle, within a helper.

Move kfree_skb() from the end of __ieee802154_rx_handle_packet() to
right after it in the calling function ieee802154_rx(). Doing so implies
reworking a little bit the exit path.

Suggested-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 net/mac802154/rx.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
index 334aa4e415cc..9f3e72a278cb 100644
--- a/net/mac802154/rx.c
+++ b/net/mac802154/rx.c
@@ -234,8 +234,6 @@ __ieee802154_rx_handle_packet(struct ieee802154_local *local,
 		skb = NULL;
 		break;
 	}
-
-	kfree_skb(skb);
 }
 
 static void
@@ -274,7 +272,7 @@ void ieee802154_rx(struct ieee802154_local *local, struct sk_buff *skb)
 	WARN_ON_ONCE(softirq_count() == 0);
 
 	if (local->suspended)
-		goto drop;
+		goto free_skb;
 
 	/* TODO: When a transceiver omits the checksum here, we
 	 * add an own calculated one. This is currently an ugly
@@ -292,20 +290,17 @@ void ieee802154_rx(struct ieee802154_local *local, struct sk_buff *skb)
 	/* Level 1 filtering: Check the FCS by software when relevant */
 	if (local->hw.phy->filtering == IEEE802154_FILTERING_NONE) {
 		crc = crc_ccitt(0, skb->data, skb->len);
-		if (crc) {
-			rcu_read_unlock();
+		if (crc)
 			goto drop;
-		}
 	}
 	/* remove crc */
 	skb_trim(skb, skb->len - 2);
 
 	__ieee802154_rx_handle_packet(local, skb);
 
-	rcu_read_unlock();
-
-	return;
 drop:
+	rcu_read_unlock();
+free_skb:
 	kfree_skb(skb);
 }
 
-- 
2.34.1

[PATCH wpan-next v2 2/3] mac802154: Clarify an expression

[Miquel Raynal]

While going through the whole interface opening logic in my head I was
consistently bothered by the condition checking whether there was only
one interface of type NODE/COORD opened at the same time. What actually
bothered me was the fact that in one case we would use the wpan_dev
pointer directly while in the other case we would use the sdata pointer,
making it harder to differentiate both. In practice the condition should
be straightforward to read. IMHO dropping the wpan_dev indirection
allows to clarify the check.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 net/mac802154/iface.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index d9b50884d34e..f21132dd82cf 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -254,7 +254,6 @@ ieee802154_check_concurrent_iface(struct ieee802154_sub_if_data *sdata,
 				  enum nl802154_iftype iftype)
 {
 	struct ieee802154_local *local = sdata->local;
-	struct wpan_dev *wpan_dev = &sdata->wpan_dev;
 	struct ieee802154_sub_if_data *nsdata;
 
 	/* we hold the RTNL here so can safely walk the list */
@@ -267,7 +266,7 @@ ieee802154_check_concurrent_iface(struct ieee802154_sub_if_data *sdata,
 			 * exist really an use case if we need to support
 			 * multiple node types at the same time.
 			 */
-			if (wpan_dev->iftype == NL802154_IFTYPE_NODE &&
+			if (sdata->wpan_dev.iftype == NL802154_IFTYPE_NODE &&
 			    nsdata->wpan_dev.iftype == NL802154_IFTYPE_NODE)
 				return -EBUSY;
 
-- 
2.34.1

[PATCH wpan-next v2 3/3] mac802154: Allow the creation of coordinator interfaces

[Miquel Raynal]

As a first strep in introducing proper PAN management and association,
we need to be able to create coordinator interfaces which might act as
coordinator or PAN coordinator.

Hence, let's add the minimum support to allow the creation of these
interfaces.

Even though the necessary logic to handle several interfaces on the same
device is added to make this future move easier, in practice only
several interfaces of type MONITOR are allowed at the same time. The
other combinations are not allowed (interface creation is possible but
only one can be opened at a time) because, with a single PHY featuring a
single set of address filters, we cannot afford handling two distinct
interfaces (with different address filters or filtering requirements):
* Having 2 NODEs, 2 COORDs or 1 NODE + 1 COORD
  -> cannot work because the address filters would be different
* Having 1 MONITOR + either 1 NODE or 1 COORD
  -> cannot work because the filtering levels are incompatible

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 net/mac802154/iface.c | 14 ++++++++------
 net/mac802154/main.c  |  2 +-
 net/mac802154/rx.c    | 11 +++++++----
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index f21132dd82cf..7de2f843379c 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -261,13 +261,13 @@ ieee802154_check_concurrent_iface(struct ieee802154_sub_if_data *sdata,
 		if (nsdata != sdata && ieee802154_sdata_running(nsdata)) {
 			int ret;
 
-			/* TODO currently we don't support multiple node types
-			 * we need to run skb_clone at rx path. Check if there
-			 * exist really an use case if we need to support
-			 * multiple node types at the same time.
+			/* TODO currently we don't support multiple node/coord
+			 * types we need to run skb_clone at rx path. Check if
+			 * there exist really an use case if we need to support
+			 * multiple node/coord types at the same time.
 			 */
-			if (sdata->wpan_dev.iftype == NL802154_IFTYPE_NODE &&
-			    nsdata->wpan_dev.iftype == NL802154_IFTYPE_NODE)
+			if (sdata->wpan_dev.iftype != NL802154_IFTYPE_MONITOR &&
+			    nsdata->wpan_dev.iftype != NL802154_IFTYPE_MONITOR)
 				return -EBUSY;
 
 			/* check all phy mac sublayer settings are the same.
@@ -564,6 +564,7 @@ ieee802154_setup_sdata(struct ieee802154_sub_if_data *sdata,
 	wpan_dev->short_addr = cpu_to_le16(IEEE802154_ADDR_BROADCAST);
 
 	switch (type) {
+	case NL802154_IFTYPE_COORD:
 	case NL802154_IFTYPE_NODE:
 		ieee802154_be64_to_le64(&wpan_dev->extended_addr,
 					sdata->dev->dev_addr);
@@ -623,6 +624,7 @@ ieee802154_if_add(struct ieee802154_local *local, const char *name,
 	ieee802154_le64_to_be64(ndev->perm_addr,
 				&local->hw.phy->perm_extended_addr);
 	switch (type) {
+	case NL802154_IFTYPE_COORD:
 	case NL802154_IFTYPE_NODE:
 		ndev->type = ARPHRD_IEEE802154;
 		if (ieee802154_is_valid_extended_unicast_addr(extended_addr)) {
diff --git a/net/mac802154/main.c b/net/mac802154/main.c
index 40fab08df24b..3ed31daf7b9c 100644
--- a/net/mac802154/main.c
+++ b/net/mac802154/main.c
@@ -107,7 +107,7 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops)
 	phy->supported.lbt = NL802154_SUPPORTED_BOOL_FALSE;
 
 	/* always supported */
-	phy->supported.iftypes = BIT(NL802154_IFTYPE_NODE);
+	phy->supported.iftypes = BIT(NL802154_IFTYPE_NODE) | BIT(NL802154_IFTYPE_COORD);
 
 	return &local->hw;
 }
diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
index 9f3e72a278cb..95633ae45510 100644
--- a/net/mac802154/rx.c
+++ b/net/mac802154/rx.c
@@ -208,6 +208,7 @@ __ieee802154_rx_handle_packet(struct ieee802154_local *local,
 	int ret;
 	struct ieee802154_sub_if_data *sdata;
 	struct ieee802154_hdr hdr;
+	struct sk_buff *skb2;
 
 	ret = ieee802154_parse_frame_start(skb, &hdr);
 	if (ret) {
@@ -217,7 +218,7 @@ __ieee802154_rx_handle_packet(struct ieee802154_local *local,
 	}
 
 	list_for_each_entry_rcu(sdata, &local->interfaces, list) {
-		if (sdata->wpan_dev.iftype != NL802154_IFTYPE_NODE)
+		if (sdata->wpan_dev.iftype == NL802154_IFTYPE_MONITOR)
 			continue;
 
 		if (!ieee802154_sdata_running(sdata))
@@ -230,9 +231,11 @@ __ieee802154_rx_handle_packet(struct ieee802154_local *local,
 		    sdata->required_filtering == IEEE802154_FILTERING_4_FRAME_FIELDS)
 			continue;
 
-		ieee802154_subif_frame(sdata, skb, &hdr);
-		skb = NULL;
-		break;
+		skb2 = skb_clone(skb, GFP_ATOMIC);
+		if (skb2) {
+			skb2->dev = sdata->dev;
+			ieee802154_subif_frame(sdata, skb2, &hdr);
+		}
 	}
 }
 
-- 
2.34.1

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Alexander Aring]

Hi,

On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hello,
> These three patches allow the creation of coordinator interfaces, which
> were already defined without being usable. The idea behind is to use
> them advertizing PANs through the beaconing feature.
>

I still don't know how exactly those "leaves" and "non-leaves" are
acting here regarding the coordinator interfaces. If this is just a
bit here to set in the interface I am fine with it. But yea,
"relaying" feature is a project on its own, as we said previously.

Another mail I was asking myself what a node interface is then,
currently it is a mesh interface with none of those 802.15.4 PAN
management functionality? Or can it act also as a "leave"
coordinator... I am not sure about that.

However I think we can think about something scheduled later as we can
still decide later if we really want that "node" can do that.
Regarding to 6LoWPAN I think the current type what "node" interface is
as a just a node in a mesh is required, it might depends on if you
want routing on IP or "relaying" on MAC (mesh-over vs mesh-under), but
I never saw mesh-under in 6LoWPAN.

Acked-by: Alexander Aring <aahringo@redhat.com>

Thanks.

- Alex

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Alexander Aring]

Hi,

On Sun, Oct 30, 2022 at 10:20 PM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hello,
> > These three patches allow the creation of coordinator interfaces, which
> > were already defined without being usable. The idea behind is to use
> > them advertizing PANs through the beaconing feature.
> >
>
> I still don't know how exactly those "leaves" and "non-leaves" are
> acting here regarding the coordinator interfaces. If this is just a
> bit here to set in the interface I am fine with it. But yea,
> "relaying" feature is a project on its own, as we said previously.
>
> Another mail I was asking myself what a node interface is then,
> currently it is a mesh interface with none of those 802.15.4 PAN
> management functionality? Or can it act also as a "leave"
> coordinator... I am not sure about that.
>
> However I think we can think about something scheduled later as we can
> still decide later if we really want that "node" can do that.
> Regarding to 6LoWPAN I think the current type what "node" interface is
> as a just a node in a mesh is required, it might depends on if you
> want routing on IP or "relaying" on MAC (mesh-over vs mesh-under), but

*route-over

> I never saw mesh-under in 6LoWPAN.
>

we will see how that works, because you can actually run a 6lowpan
interface on the new coordinator type.

- Alex

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Sun, 30 Oct 2022 22:20:03 -0400:

> Hi,
> 
> On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hello,
> > These three patches allow the creation of coordinator interfaces, which
> > were already defined without being usable. The idea behind is to use
> > them advertizing PANs through the beaconing feature.
> >  
> 
> I still don't know how exactly those "leaves" and "non-leaves" are
> acting here regarding the coordinator interfaces. If this is just a
> bit here to set in the interface I am fine with it. But yea,
> "relaying" feature is a project on its own, as we said previously.
> 
> Another mail I was asking myself what a node interface is then,
> currently it is a mesh interface with none of those 802.15.4 PAN
> management functionality?

Not "none", because I would expect a NODE to be able to perform minimal
management operations, such as:
- scanning
- requesting an association
But in no case it is supposed to:
- send beacons
- manage associations
- be the PAN coordinator
- act as a relay

> Or can it act also as a "leave"
> coordinator... I am not sure about that.
> 
> However I think we can think about something scheduled later as we can
> still decide later if we really want that "node" can do that.
> Regarding to 6LoWPAN I think the current type what "node" interface is
> as a just a node in a mesh is required, it might depends on if you
> want routing on IP or "relaying" on MAC (mesh-over vs mesh-under), but
> I never saw mesh-under in 6LoWPAN.

Yes.

> 
> Acked-by: Alexander Aring <aahringo@redhat.com>

Thanks!

Miquèl

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Alexander Aring]

Hi,

On Wed, Nov 2, 2022 at 10:52 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Sun, 30 Oct 2022 22:20:03 -0400:
>
> > Hi,
> >
> > On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hello,
> > > These three patches allow the creation of coordinator interfaces, which
> > > were already defined without being usable. The idea behind is to use
> > > them advertizing PANs through the beaconing feature.
> > >
> >
> > I still don't know how exactly those "leaves" and "non-leaves" are
> > acting here regarding the coordinator interfaces. If this is just a
> > bit here to set in the interface I am fine with it. But yea,
> > "relaying" feature is a project on its own, as we said previously.
> >
> > Another mail I was asking myself what a node interface is then,
> > currently it is a mesh interface with none of those 802.15.4 PAN
> > management functionality?
>
> Not "none", because I would expect a NODE to be able to perform minimal
> management operations, such as:
> - scanning
> - requesting an association
> But in no case it is supposed to:
> - send beacons
> - manage associations
> - be the PAN coordinator
> - act as a relay
>

perfect, thanks. But still there is something which I don't get.

The split you mentioned about the functionality is for me being a
coordinator (IEEE spec) or pan coordinator (IEEE spec) which has the
additional functionality of "send beacons, manage assocs, act as
relay".
So a coordinator (iftype) is a pan coordinator (IEEE spec) and a node
(iftype) is a coordinator (IEEE spec), but _only_ when it's
associated, before it is just a manually setup mesh node?

I hope it's clear when meaning iftype and when meaning IEEE spec, but
for the manual setup thing (node iftype) there is no IEEE spec,
although it is legal to do it in my opinion.

Thanks.

- Alex

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Thu, 3 Nov 2022 20:55:38 -0400:

> Hi,
> 
> On Wed, Nov 2, 2022 at 10:52 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Sun, 30 Oct 2022 22:20:03 -0400:
> >  
> > > Hi,
> > >
> > > On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > Hello,
> > > > These three patches allow the creation of coordinator interfaces, which
> > > > were already defined without being usable. The idea behind is to use
> > > > them advertizing PANs through the beaconing feature.
> > > >  
> > >
> > > I still don't know how exactly those "leaves" and "non-leaves" are
> > > acting here regarding the coordinator interfaces. If this is just a
> > > bit here to set in the interface I am fine with it. But yea,
> > > "relaying" feature is a project on its own, as we said previously.
> > >
> > > Another mail I was asking myself what a node interface is then,
> > > currently it is a mesh interface with none of those 802.15.4 PAN
> > > management functionality?  
> >
> > Not "none", because I would expect a NODE to be able to perform minimal
> > management operations, such as:
> > - scanning
> > - requesting an association
> > But in no case it is supposed to:
> > - send beacons
> > - manage associations
> > - be the PAN coordinator
> > - act as a relay
> >  
> 
> perfect, thanks. But still there is something which I don't get.
> 
> The split you mentioned about the functionality is for me being a
> coordinator (IEEE spec) or pan coordinator (IEEE spec) which has the
> additional functionality of "send beacons, manage assocs, act as
> relay".

I would expect any coordinator (IEEE spec) to be able to send beacons
and relay (but in this case it only makes sense to send beacons if
relaying is supported, IMHO).

The PAN coordinator (IEEE spec) only has the following additional
capability: managing assocs within the PAN. But in practice it is very
likely that it is the one with the greater computational resources and
the highest networking capabilities (it is usually the one which acts
as a bridge with eg. the internet, says the spec).

> So a coordinator (iftype) is a pan coordinator (IEEE spec) and a node
> (iftype) is a coordinator (IEEE spec), but _only_ when it's
> associated, before it is just a manually setup mesh node?

Mmmh, actually this is not how I see it. My current mental model:
- COORD (iftype) may act as:
  * a leaf device (associating with the PAN coordinator, sending data)
  * a coordinator (like above + beaconing and relaying) once associated
  * a PAN coordinator (like above + assoc management) if the device
    started the PAN or after a PAN coordinator handover.
  Note: physically, it can only be authorized on FFD.
- NODE (iftype) may only be a leaf device no matter its association
  status, this is typically a sensor that sends data.
  Note: can be authorized on any type of device (FFD or RFD).

If I understand correctly, your idea was to change the interface type
depending of the role of the device within the network. But IMHO the
interface type should only be picked up once for all in the lifetime of
the device. Of course we can switch from one to another by quickly
turning off and on again the device, but this is not a common use case.
We must keep in mind that PAN coordinator handover may happen, which
means the interface must stay on but stop acting as the PAN
coordinator. Using two different interface types for that is not
impossible, but does not seem relevant to me.

Would you agree?

> I hope it's clear when meaning iftype and when meaning IEEE spec, but
> for the manual setup thing (node iftype) there is no IEEE spec,
> although it is legal to do it in my opinion.

It's clear, no problem. In my previous e-mails, when talking about the
interfaces I used the uppercase NODE and COORD keywords, while I used
the plain english lowercase "[leaf] node", "coordinator" or "PAN
coordinator" words when talking about the IEEE definitions.

Thanks,
Miquèl

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Alexander Aring]

Hi,

On Fri, Nov 4, 2022 at 2:17 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Thu, 3 Nov 2022 20:55:38 -0400:
>
> > Hi,
> >
> > On Wed, Nov 2, 2022 at 10:52 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Alexander,
> > >
> > > aahringo@redhat.com wrote on Sun, 30 Oct 2022 22:20:03 -0400:
> > >
> > > > Hi,
> > > >
> > > > On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hello,
> > > > > These three patches allow the creation of coordinator interfaces, which
> > > > > were already defined without being usable. The idea behind is to use
> > > > > them advertizing PANs through the beaconing feature.
> > > > >
> > > >
> > > > I still don't know how exactly those "leaves" and "non-leaves" are
> > > > acting here regarding the coordinator interfaces. If this is just a
> > > > bit here to set in the interface I am fine with it. But yea,
> > > > "relaying" feature is a project on its own, as we said previously.
> > > >
> > > > Another mail I was asking myself what a node interface is then,
> > > > currently it is a mesh interface with none of those 802.15.4 PAN
> > > > management functionality?
> > >
> > > Not "none", because I would expect a NODE to be able to perform minimal
> > > management operations, such as:
> > > - scanning
> > > - requesting an association
> > > But in no case it is supposed to:
> > > - send beacons
> > > - manage associations
> > > - be the PAN coordinator
> > > - act as a relay
> > >
> >
> > perfect, thanks. But still there is something which I don't get.
> >
> > The split you mentioned about the functionality is for me being a
> > coordinator (IEEE spec) or pan coordinator (IEEE spec) which has the
> > additional functionality of "send beacons, manage assocs, act as
> > relay".
>
> I would expect any coordinator (IEEE spec) to be able to send beacons
> and relay (but in this case it only makes sense to send beacons if
> relaying is supported, IMHO).
>
> The PAN coordinator (IEEE spec) only has the following additional
> capability: managing assocs within the PAN. But in practice it is very
> likely that it is the one with the greater computational resources and
> the highest networking capabilities (it is usually the one which acts
> as a bridge with eg. the internet, says the spec).
>
> > So a coordinator (iftype) is a pan coordinator (IEEE spec) and a node
> > (iftype) is a coordinator (IEEE spec), but _only_ when it's
> > associated, before it is just a manually setup mesh node?
>
> Mmmh, actually this is not how I see it. My current mental model:
> - COORD (iftype) may act as:
>   * a leaf device (associating with the PAN coordinator, sending data)
>   * a coordinator (like above + beaconing and relaying) once associated
>   * a PAN coordinator (like above + assoc management) if the device
>     started the PAN or after a PAN coordinator handover.
>   Note: physically, it can only be authorized on FFD.
> - NODE (iftype) may only be a leaf device no matter its association
>   status, this is typically a sensor that sends data.
>   Note: can be authorized on any type of device (FFD or RFD).
>
> If I understand correctly, your idea was to change the interface type
> depending of the role of the device within the network. But IMHO the
> interface type should only be picked up once for all in the lifetime of
> the device. Of course we can switch from one to another by quickly
> turning off and on again the device, but this is not a common use case.
> We must keep in mind that PAN coordinator handover may happen, which
> means the interface must stay on but stop acting as the PAN
> coordinator. Using two different interface types for that is not
> impossible, but does not seem relevant to me.
>
> Would you agree?
>

Okay, I think that if you have a node then you never want to act as
any PAN coordinators functionality. And yes it seems complicated to
switch such functionality during runtime. I am fine with that. The
future will show if there are any "special" requirements and how we
could react here.

> > I hope it's clear when meaning iftype and when meaning IEEE spec, but
> > for the manual setup thing (node iftype) there is no IEEE spec,
> > although it is legal to do it in my opinion.
>
> It's clear, no problem. In my previous e-mails, when talking about the
> interfaces I used the uppercase NODE and COORD keywords, while I used
> the plain english lowercase "[leaf] node", "coordinator" or "PAN
> coordinator" words when talking about the IEEE definitions.
>

That is great, we should use those terms to make the difference.

Thanks.

- Alex

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Sun, 6 Nov 2022 20:30:48 -0500:

> Hi,
> 
> On Fri, Nov 4, 2022 at 2:17 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Thu, 3 Nov 2022 20:55:38 -0400:
> >  
> > > Hi,
> > >
> > > On Wed, Nov 2, 2022 at 10:52 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > Hi Alexander,
> > > >
> > > > aahringo@redhat.com wrote on Sun, 30 Oct 2022 22:20:03 -0400:
> > > >  
> > > > > Hi,
> > > > >
> > > > > On Wed, Oct 26, 2022 at 5:35 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > > >
> > > > > > Hello,
> > > > > > These three patches allow the creation of coordinator interfaces, which
> > > > > > were already defined without being usable. The idea behind is to use
> > > > > > them advertizing PANs through the beaconing feature.
> > > > > >  
> > > > >
> > > > > I still don't know how exactly those "leaves" and "non-leaves" are
> > > > > acting here regarding the coordinator interfaces. If this is just a
> > > > > bit here to set in the interface I am fine with it. But yea,
> > > > > "relaying" feature is a project on its own, as we said previously.
> > > > >
> > > > > Another mail I was asking myself what a node interface is then,
> > > > > currently it is a mesh interface with none of those 802.15.4 PAN
> > > > > management functionality?  
> > > >
> > > > Not "none", because I would expect a NODE to be able to perform minimal
> > > > management operations, such as:
> > > > - scanning
> > > > - requesting an association
> > > > But in no case it is supposed to:
> > > > - send beacons
> > > > - manage associations
> > > > - be the PAN coordinator
> > > > - act as a relay
> > > >  
> > >
> > > perfect, thanks. But still there is something which I don't get.
> > >
> > > The split you mentioned about the functionality is for me being a
> > > coordinator (IEEE spec) or pan coordinator (IEEE spec) which has the
> > > additional functionality of "send beacons, manage assocs, act as
> > > relay".  
> >
> > I would expect any coordinator (IEEE spec) to be able to send beacons
> > and relay (but in this case it only makes sense to send beacons if
> > relaying is supported, IMHO).
> >
> > The PAN coordinator (IEEE spec) only has the following additional
> > capability: managing assocs within the PAN. But in practice it is very
> > likely that it is the one with the greater computational resources and
> > the highest networking capabilities (it is usually the one which acts
> > as a bridge with eg. the internet, says the spec).
> >  
> > > So a coordinator (iftype) is a pan coordinator (IEEE spec) and a node
> > > (iftype) is a coordinator (IEEE spec), but _only_ when it's
> > > associated, before it is just a manually setup mesh node?  
> >
> > Mmmh, actually this is not how I see it. My current mental model:
> > - COORD (iftype) may act as:
> >   * a leaf device (associating with the PAN coordinator, sending data)
> >   * a coordinator (like above + beaconing and relaying) once associated
> >   * a PAN coordinator (like above + assoc management) if the device
> >     started the PAN or after a PAN coordinator handover.
> >   Note: physically, it can only be authorized on FFD.
> > - NODE (iftype) may only be a leaf device no matter its association
> >   status, this is typically a sensor that sends data.
> >   Note: can be authorized on any type of device (FFD or RFD).
> >
> > If I understand correctly, your idea was to change the interface type
> > depending of the role of the device within the network. But IMHO the
> > interface type should only be picked up once for all in the lifetime of
> > the device. Of course we can switch from one to another by quickly
> > turning off and on again the device, but this is not a common use case.
> > We must keep in mind that PAN coordinator handover may happen, which
> > means the interface must stay on but stop acting as the PAN
> > coordinator. Using two different interface types for that is not
> > impossible, but does not seem relevant to me.
> >
> > Would you agree?
> >  
> 
> Okay, I think that if you have a node then you never want to act as
> any PAN coordinators functionality. And yes it seems complicated to
> switch such functionality during runtime. I am fine with that.

Great!

> The
> future will show if there are any "special" requirements and how we
> could react here.

Agreed.

> > > I hope it's clear when meaning iftype and when meaning IEEE spec, but
> > > for the manual setup thing (node iftype) there is no IEEE spec,
> > > although it is legal to do it in my opinion.  
> >
> > It's clear, no problem. In my previous e-mails, when talking about the
> > interfaces I used the uppercase NODE and COORD keywords, while I used
> > the plain english lowercase "[leaf] node", "coordinator" or "PAN
> > coordinator" words when talking about the IEEE definitions.
> >  
> 
> That is great, we should use those terms to make the difference.

Ok, I'll do!

Thanks,
Miquèl

Re: [PATCH wpan-next v2 0/3] IEEE 802.15.4: Add coordinator interfaces

[Stefan Schmidt]

Hello.

On 26.10.22 11:34, Miquel Raynal wrote:
> Hello,
> These three patches allow the creation of coordinator interfaces, which
> were already defined without being usable. The idea behind is to use
> them advertizing PANs through the beaconing feature.
> 
> Changes since v1:
> * Addition of patches 1 and 2.
> * Improved the commit message of patch 3.
> * Rebased.
> * Minor fixes.
> 
> Miquel Raynal (3):
>    mac802154: Move an skb free within the rx path
>    mac802154: Clarify an expression
>    mac802154: Allow the creation of coordinator interfaces
> 
>   net/mac802154/iface.c | 15 ++++++++-------
>   net/mac802154/main.c  |  2 +-
>   net/mac802154/rx.c    | 24 +++++++++++-------------
>   3 files changed, 20 insertions(+), 21 deletions(-)


These patches have been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!

regards
Stefan Schmidt