[PATCH wpan-next v5 00/11] ieee802154: Associations between devices

* [PATCH wpan-next v5 00/11] ieee802154: Associations between devices
@ 2023-09-27 18:12 Miquel Raynal
  2023-09-27 18:12 ` [PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset Miquel Raynal
                   ` (11 more replies)
  0 siblings, 12 replies; 28+ messages in thread
From: Miquel Raynal @ 2023-09-27 18:12 UTC (permalink / raw)
  To: Alexander Aring, Stefan Schmidt, linux-wpan
  Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Eric Dumazet,
	netdev, David Girault, Romuald Despres, Frederic Blain,
	Nicolas Schodet, Guilhem Imberton, Thomas Petazzoni,
	Miquel Raynal

Hello,

Now that we can discover our peer coordinators or make ourselves
dynamically discoverable, we may use the information about surrounding
devices to create PANs dynamically. This involves of course:
* Requesting an association to a coordinator, waiting for the response
* Sending a disassociation notification to a coordinator
* Receiving an association request when we are coordinator, answering
  the request (for now all devices are accepted up to a limit, to be
  refined)
* Sending a disassociation notification to a child
* Users may request the list of associated devices (the parent and the
  children).

Here are a few example of userspace calls that can be made:
iwpan dev <dev> associate pan_id 2 coord $COORD
iwpan dev <dev> list_associations
iwpan dev <dev> disassociate ext_addr $COORD

I used a small using hwsim to scan for a coordinator, associate with
it, look at the associations on both sides, disassociate from it and
check the associations again:
./assoc-demo
*** Scan ***
PAN 0x0002 (on wpan1)
	coordinator 0x060f3b35169a498f
	page 0
	channel 13
	preamble code 0
	mean prf 0
	superframe spec. 0xcf11
	LQI ff
*** End of scan ***
Associating wpan1 with coord0 0x060f3b35169a498f...
Dumping coord0 assoc:
child : 0x0b6f / 0xba7633ae47ccfb21
Dumping wpan1 assoc:
parent: 0xffff / 0x060f3b35169a498f
Disassociating from wpan1
Dumping coord0 assoc:
Dumping wpan1 assoc:

I could also successfully interact with a smaller device running Zephir,
using its command line interface to associate and then disassociate from
the Linux coordinator.

Thanks!
Miquèl

Changes in v5:
* Fixed (again) the helper supposed to check whether a device requesting
  association/disassociation is already (or not) in our PAN. We don't
  nee to check short addresses there.
* Changed the name of the helper a second time to make it more relevant
  and understandable:
  cfg802154_device_in_pan() -> cfg802154_pan_device_is_matching()
* Fixed a kernel test robot report where we would use an int instead of
  a __le16. Solved that by using cpu_to_le16 like in the other places
  where we use definitions as arguments.

Changes in v4:
* Ensured any disassociation would only be processed if the destination
  pan ID matches ours.
* Association requests should be made using extended addressing, it's
  the specification, so ensure this is true. Doing so helps reducing the
  checks down the road.
* Updated a copyright from 2021 to 2023.
* Improved the comment for cfg802154_device_in_pan() and only accept
  extended addressing when using this internal function because there is
  no point in checking short addresses here.
* Move nl802154_prepare_wpan_dev_dump() and
  nl802154_finish_wpan_dev_dump() outside of a
  CONFIG_IEEE802154_NL802154_EXPERIMENTAL #ifdef bloc as now used in
  regular code (not only experimental).
* Added a missing return value in the kernel doc of
  cfg802154_device_is_associated().

Changes in v3:
* Clarify a helper which compares if two devices seem to be identical by
  adding two comments. This is a static function that is only used by
  the PAN management core to operate or not an
  association/disassociation request. In this helper, a new check is
  introduced to be sure we compare fields which have been populated.
* Dropped the "association_generation" counter and all its uses along
  the code. I tried to mimic some other counter but I agree it is not
  super useful and could be dropped anyway.
* Dropped a faulty sequence number hardcoded to 10. This had no impact
  because a few lines later the same entry was set to a valid value.

Changes in v2:
* Drop the misleading IEEE802154_ADDR_LONG_BROADCAST definition and its
  only use which was useless anyway.
* Clarified how devices are defined when the user requests to associate
  with a coordinator: for now only the extended address of the
  coordinator is relevant so this is the only address we care about.
* Drop a useless NULL check before a kfree() call.
* Add a check when allocating a child short address: it must be
  different than ours.
* Rebased on top of v6.5.

Miquel Raynal (11):
  ieee802154: Let PAN IDs be reset
  ieee802154: Internal PAN management
  ieee802154: Add support for user association requests
  mac802154: Handle associating
  ieee802154: Add support for user disassociation requests
  mac802154: Handle disassociations
  mac802154: Handle association requests from peers
  ieee802154: Add support for limiting the number of associated devices
  mac802154: Follow the number of associated devices
  mac802154: Handle disassociation notifications from peers
  ieee802154: Give the user the association list

 include/net/cfg802154.h         |  70 ++++++
 include/net/ieee802154_netdev.h |  60 +++++
 include/net/nl802154.h          |  22 +-
 net/ieee802154/Makefile         |   2 +-
 net/ieee802154/core.c           |  24 ++
 net/ieee802154/nl802154.c       | 225 +++++++++++++++++-
 net/ieee802154/pan.c            | 103 +++++++++
 net/ieee802154/rdev-ops.h       |  30 +++
 net/ieee802154/trace.h          |  38 +++
 net/mac802154/cfg.c             | 170 ++++++++++++++
 net/mac802154/ieee802154_i.h    |  27 +++
 net/mac802154/main.c            |   2 +
 net/mac802154/rx.c              |  25 ++
 net/mac802154/scan.c            | 397 ++++++++++++++++++++++++++++++++
 14 files changed, 1180 insertions(+), 15 deletions(-)
 create mode 100644 net/ieee802154/pan.c

-- 
2.34.1

^ permalink raw reply	[flat|nested] 28+ messages in thread