[PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Miquel Raynal]

Hello,

This series follows the work done in the Linux kernel stack: now that
the core knows about the different netlink commands and attributes in
order to support scanning and beaconing requests from end-to-end, here
are the userspace changes to be able to use it.

Here is a list of the new available features.

* Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
  valid for passively sending beacons at regular intervals. An interval
  of 15 would request the core to answer BEACON_REQ.
  # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
  # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
  # iwpan dev coord0 beacons stop # apply to both cases

* Scanning all the channels or only a subset:
  # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
  # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ

* During scans, there is a dedicated netlink channel event to listen to
  in order to get events like "a new coordinator was discovered" or "the
  scan is over". When beacons from new devices are received, the tool
  would print something like:
  PAN 0xabcd (on coord1)
	coordinator 0xe673d7a3f3a87ccc
	page 0
	channel 13
	preamble code 0
	mean prf 0
	superframe spec. 0x4f11
	LQI 0

* It is also possible to monitor the events with:
  # iwpan event

* As well as triggering a non blocking scan:
  # iwpan dev wpan1 scan trigger type passive duration 3
  # iwpan dev wpan1 scan done
  # iwpan dev wpan1 scan abort

Associations will be handled in another series.

Cheers,
Miquèl

David Girault (4):
  iwpan: Export iwpan_debug
  iwpan: Remove duplicated SECTION
  iwpan: Add full scan support
  iwpan: Add events support

Miquel Raynal (2):
  iwpan: Fix a comment
  iwpan: Synchronize nl802154 header with the Linux kernel

Romuald Despres (1):
  iwpan: Fix the channels printing

 src/Makefile.am |   2 +
 src/event.c     | 222 +++++++++++++++++++++++++
 src/info.c      |   2 +-
 src/iwpan.c     |   2 +-
 src/iwpan.h     |  13 +-
 src/mac.c       |   1 +
 src/nl802154.h  |  93 +++++++++++
 src/scan.c      | 420 ++++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 746 insertions(+), 9 deletions(-)
 create mode 100644 src/event.c
 create mode 100644 src/scan.c

-- 
2.34.1

[PATCH wpan-tools 1/7] iwpan: Fix the channels printing

[Miquel Raynal]

From: Romuald Despres <Romuald.Despres@qorvo.com>

The presence of a channel capability is checked against the tb_msg
netlink attributes array which is the root one, while here we are
looking for channel capabilities, themselves being nested and parsed
into tb_caps. Use tb_caps instead of tb_msg here otherwise we are
accessing a random index in the upper attributes list.

Signed-off-by: Romuald Despres <Romuald.Despres@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/info.c b/src/info.c
index f85690c..8ed5e4f 100644
--- a/src/info.c
+++ b/src/info.c
@@ -342,7 +342,7 @@ static int print_phy_handler(struct nl_msg *msg, void *arg)
 			printf("\b \n");
 		}
 
-		if (tb_msg[NL802154_CAP_ATTR_CHANNELS]) {
+		if (tb_caps[NL802154_CAP_ATTR_CHANNELS]) {
 			int counter = 0;
 			int rem_pages;
 			struct nlattr *nl_pages;
-- 
2.34.1

[PATCH wpan-tools 2/7] iwpan: Export iwpan_debug

[Miquel Raynal]

From: David Girault <david.girault@qorvo.com>

This debug flag will be used later on in different files.

Signed-off-by: David Girault <david.girault@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/iwpan.c | 2 +-
 src/iwpan.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/iwpan.c b/src/iwpan.c
index fb7bef1..3cf5fe2 100644
--- a/src/iwpan.c
+++ b/src/iwpan.c
@@ -21,7 +21,7 @@
 
 /* TODO libnl 1.x compatibility code */
 
-static int iwpan_debug = 0;
+int iwpan_debug = 0;
 
 static int nl802154_init(struct nl802154_state *state)
 {
diff --git a/src/iwpan.h b/src/iwpan.h
index 48c4f03..860dd37 100644
--- a/src/iwpan.h
+++ b/src/iwpan.h
@@ -120,4 +120,6 @@ DECLARE_SECTION(get);
 
 const char *iftype_name(enum nl802154_iftype iftype);
 
+extern int iwpan_debug;
+
 #endif /* __IWPAN_H */
-- 
2.34.1

[PATCH wpan-tools 3/7] iwpan: Fix a comment

[Miquel Raynal]

There are a couple of words missing, add them to clarify the comment.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/iwpan.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/iwpan.h b/src/iwpan.h
index 860dd37..9d265c6 100644
--- a/src/iwpan.h
+++ b/src/iwpan.h
@@ -43,7 +43,7 @@ struct cmd {
 	const enum command_identify_by idby;
 	/* The handler should return a negative error code,
 	 * zero on success, 1 if the arguments were wrong
-	 * and the usage message should and 2 otherwise.
+	 * and the usage message should be displayed, 2 otherwise.
 	 */
 	int (*handler)(struct nl802154_state *state,
 		       struct nl_cb *cb,
-- 
2.34.1

[PATCH wpan-tools 4/7] iwpan: Remove duplicated SECTION

[Miquel Raynal]

From: David Girault <david.girault@qorvo.com>

This section has been duplicated, drop one.

Signed-off-by: David Girault <david.girault@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/iwpan.h | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/src/iwpan.h b/src/iwpan.h
index 9d265c6..406940a 100644
--- a/src/iwpan.h
+++ b/src/iwpan.h
@@ -90,12 +90,6 @@ struct cmd {
 		.handler = (_handler),					\
 		.help = (_help),					\
 	 }
-#define SECTION(_name)							\
-	struct cmd __section ## _ ## _name				\
-	__attribute__((used)) __attribute__((section("__cmd"))) = {	\
-		.name = (#_name),					\
-		.hidden = 1,						\
-	}
 
 #define SECTION(_name)							\
 	struct cmd __section ## _ ## _name				\
-- 
2.34.1

Re: [PATCH wpan-tools 4/7] iwpan: Remove duplicated SECTION

[Alexander Aring]

Hi,

On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> From: David Girault <david.girault@qorvo.com>
>
> This section has been duplicated, drop one.
>
> Signed-off-by: David Girault <david.girault@qorvo.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Patch 1, 2, 3 and 4 seems to be fine. So far I know we don't do
Signed-off-by on wpan-tools but it doesn't harm it is there as Stefan
would say "there is no description what to sign for".

Stefan can you take care of this I know that there is a automated ci
stuff going on which you setup (thanks again for doing it) is it just
easy as commit it to the branch "coverity_scan" and if everything is
fine it gets automatically into master (just to confirm the process
here again)?

Thanks.

- Alex

[PATCH wpan-tools 5/7] iwpan: Synchronize nl802154 header with the Linux kernel

[Miquel Raynal]

The content of this file as evolved, reflect the changes accepted in the
mainline Linux kernel here.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/nl802154.h | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/src/nl802154.h b/src/nl802154.h
index ddcee12..a9c06f3 100644
--- a/src/nl802154.h
+++ b/src/nl802154.h
@@ -56,6 +56,13 @@ enum nl802154_commands {
 
 	NL802154_CMD_SET_WPAN_PHY_NETNS,
 
+	NL802154_CMD_NEW_COORDINATOR,
+	NL802154_CMD_TRIGGER_SCAN,
+	NL802154_CMD_ABORT_SCAN,
+	NL802154_CMD_SCAN_DONE,
+	NL802154_CMD_SEND_BEACONS,
+	NL802154_CMD_STOP_BEACONS,
+
 	/* add new commands above here */
 
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
@@ -131,6 +138,13 @@ enum nl802154_attrs {
 	NL802154_ATTR_PID,
 	NL802154_ATTR_NETNS_FD,
 
+	NL802154_ATTR_COORDINATOR,
+	NL802154_ATTR_SCAN_TYPE,
+	NL802154_ATTR_SCAN_FLAGS,
+	NL802154_ATTR_SCAN_CHANNELS,
+	NL802154_ATTR_SCAN_DURATION,
+	NL802154_ATTR_BEACON_INTERVAL,
+
 	/* add attributes here, update the policy in nl802154.c */
 
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
@@ -217,6 +231,85 @@ enum nl802154_wpan_phy_capability_attr {
 	NL802154_CAP_ATTR_MAX = __NL802154_CAP_ATTR_AFTER_LAST - 1
 };
 
+/**
+ * enum nl802154_scan_types - Scan types
+ *
+ * @__NL802154_SCAN_INVALID: scan type number 0 is reserved
+ * @NL802154_SCAN_ED: An ED scan allows a device to obtain a measure of the peak
+ *	energy in each requested channel
+ * @NL802154_SCAN_ACTIVE: Locate any coordinator transmitting Beacon frames using
+ *	a Beacon Request command
+ * @NL802154_SCAN_PASSIVE: Locate any coordinator transmitting Beacon frames
+ * @NL802154_SCAN_ORPHAN: Relocate coordinator following a loss of synchronisation
+ * @NL802154_SCAN_ENHANCED_ACTIVE: Same as Active using Enhanced Beacon Request
+ *	command instead of Beacon Request command
+ * @NL802154_SCAN_RIT_PASSIVE: Passive scan for RIT Data Request command frames
+ *	instead of Beacon frames
+ * @NL802154_SCAN_ATTR_MAX: Maximum SCAN attribute number
+ */
+enum nl802154_scan_types {
+	__NL802154_SCAN_INVALID,
+	NL802154_SCAN_ED,
+	NL802154_SCAN_ACTIVE,
+	NL802154_SCAN_PASSIVE,
+	NL802154_SCAN_ORPHAN,
+	NL802154_SCAN_ENHANCED_ACTIVE,
+	NL802154_SCAN_RIT_PASSIVE,
+
+	/* keep last */
+	NL802154_SCAN_ATTR_MAX,
+};
+
+/**
+ * enum nl802154_scan_flags - Scan request control flags
+ *
+ * @NL802154_SCAN_FLAG_RANDOM_ADDR: use a random MAC address for this scan (ie.
+ *	a different one for every scan iteration). When the flag is set, full
+ *	randomisation is assumed.
+ */
+enum nl802154_scan_flags {
+	NL802154_SCAN_FLAG_RANDOM_ADDR = 1 << 0,
+};
+
+/**
+ * enum nl802154_coord - Netlink attributes for a coordinator
+ *
+ * @__NL802154_COORD_INVALID: invalid
+ * @NL802154_COORD_PANID: PANID of the coordinator (2 bytes)
+ * @NL802154_COORD_ADDR: Coordinator address, (8 bytes or 2 bytes)
+ * @NL802154_COORD_CHANNEL: channel number, related to @NL802154_COORD_PAGE (u8)
+ * @NL802154_COORD_PAGE: channel page, related to @NL802154_COORD_CHANNEL (u8)
+ * @NL802154_COORD_PREAMBLE_CODE: Preamble code used when the beacon was received,
+ *     this is PHY dependent and optional (u8)
+ * @NL802154_COORD_MEAN_PRF: Mean PRF used when the beacon was received,
+ *     this is PHY dependent and optional (u8)
+ * @NL802154_COORD_SUPERFRAME_SPEC: superframe specification of the PAN (u16)
+ * @NL802154_COORD_LINK_QUALITY: signal quality of beacon in unspecified units,
+ *	scaled to 0..255 (u8)
+ * @NL802154_COORD_GTS_PERMIT: set to true if GTS is permitted on this PAN
+ * @NL802154_COORD_PAYLOAD_DATA: binary data containing the raw data from the
+ *	frame payload, (only if beacon or probe response had data)
+ * @NL802154_COORD_PAD: attribute used for padding for 64-bit alignment
+ * @NL802154_COORD_MAX: highest coordinator attribute
+ */
+enum nl802154_coord {
+	__NL802154_COORD_INVALID,
+	NL802154_COORD_PANID,
+	NL802154_COORD_ADDR,
+	NL802154_COORD_CHANNEL,
+	NL802154_COORD_PAGE,
+	NL802154_COORD_PREAMBLE_CODE,
+	NL802154_COORD_MEAN_PRF,
+	NL802154_COORD_SUPERFRAME_SPEC,
+	NL802154_COORD_LINK_QUALITY,
+	NL802154_COORD_GTS_PERMIT,
+	NL802154_COORD_PAYLOAD_DATA,
+	NL802154_COORD_PAD,
+
+	/* keep last */
+	NL802154_COORD_MAX,
+};
+
 /**
  * enum nl802154_cca_modes - cca modes
  *
-- 
2.34.1

[PATCH wpan-tools 6/7] iwpan: Add full scan support

[Miquel Raynal]

From: David Girault <david.girault@qorvo.com>

Bring support for different scanning operations, such as starting or
aborting a scan operation with a given configuration, and dumping the
discovered coordinators.

It also brings support for additional PAN management features, such as a
beacon request to ask the mac to send or stop sending beacons out of a
particular interface.

Signed-off-by: David Girault <david.girault@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/Makefile.am |   1 +
 src/mac.c       |   1 +
 src/scan.c      | 421 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 423 insertions(+)
 create mode 100644 src/scan.c

diff --git a/src/Makefile.am b/src/Makefile.am
index 2d54576..18b3569 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -9,6 +9,7 @@ iwpan_SOURCES = \
 	interface.c \
 	phy.c \
 	mac.c \
+	scan.c \
 	nl_extras.h \
 	nl802154.h
 
diff --git a/src/mac.c b/src/mac.c
index 286802c..19bb328 100644
--- a/src/mac.c
+++ b/src/mac.c
@@ -234,3 +234,4 @@ nla_put_failure:
 COMMAND(set, ackreq_default, "<1|0>",
 	NL802154_CMD_SET_ACKREQ_DEFAULT, 0, CIB_NETDEV, handle_ackreq_default,
 	NULL);
+
diff --git a/src/scan.c b/src/scan.c
new file mode 100644
index 0000000..de6caf4
--- /dev/null
+++ b/src/scan.c
@@ -0,0 +1,421 @@
+#include <net/if.h>
+#include <errno.h>
+#include <string.h>
+#include <stdbool.h>
+#include <inttypes.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl802154.h"
+#include "nl_extras.h"
+#include "iwpan.h"
+
+static char scantypebuf[100];
+
+static const char *scantype_name(enum nl802154_scan_types scantype)
+{
+	switch (scantype) {
+	case NL802154_SCAN_ED:
+		return "ed";
+	case NL802154_SCAN_ACTIVE:
+		return "active";
+	case NL802154_SCAN_PASSIVE:
+		return "passive";
+	case NL802154_SCAN_ENHANCED_ACTIVE:
+		return "enhanced";
+	case NL802154_SCAN_RIT_PASSIVE:
+		return "rit";
+	default:
+		sprintf(scantypebuf, "Invalid scantype (%d)", scantype);
+		return scantypebuf;
+	}
+}
+
+/* for help */
+#define SCAN_TYPES "Valid scanning types are: ed, active, passive, enhanced, rit."
+
+/* return 0 if ok, internal error otherwise */
+static int get_scan_type(int *argc, char ***argv, enum nl802154_scan_types *type)
+{
+	char *tpstr;
+
+	if (*argc < 2)
+		return 1;
+
+	if (strcmp((*argv)[0], "type"))
+		return 1;
+
+	tpstr = (*argv)[1];
+	*argc -= 2;
+	*argv += 2;
+
+	if (strcmp(tpstr, "ed") == 0) {
+		*type = NL802154_SCAN_ED;
+		return 0;
+	} else if (strcmp(tpstr, "active") == 0) {
+		*type = NL802154_SCAN_ACTIVE;
+		return 0;
+	} else if (strcmp(tpstr, "passive") == 0) {
+		*type = NL802154_SCAN_PASSIVE;
+		return 0;
+	} else if (strcmp(tpstr, "enhanced") == 0) {
+		*type = NL802154_SCAN_ENHANCED_ACTIVE;
+		return 0;
+	} else if (strcmp(tpstr, "rit") == 0) {
+		*type = NL802154_SCAN_RIT_PASSIVE;
+		return 0;
+	}
+
+	fprintf(stderr, "invalid interface type %s\n", tpstr);
+	return 2;
+}
+
+static int get_option_value(int *argc, char ***argv, const char *marker, unsigned long *result, bool *valid)
+{
+	unsigned long value;
+	char *tpstr, *end;
+
+	*valid = false;
+
+	if (*argc < 2)
+		return 0;
+
+	if (strcmp((*argv)[0], marker))
+		return 0;
+
+	tpstr = (*argv)[1];
+	*argc -= 2;
+	*argv += 2;
+
+	value = strtoul(tpstr, &end, 0);
+	if (*end != '\0')
+		return 1;
+
+	*result = value;
+	*valid = true;
+
+	return 0;
+}
+
+static int scan_trigger_handler(struct nl802154_state *state,
+				struct nl_cb *cb,
+				struct nl_msg *msg,
+				int argc, char **argv,
+				enum id_input id)
+{
+	enum nl802154_scan_types type;
+	unsigned long page, channels, duration;
+	int tpset;
+	bool valid_page, valid_channels, valid_duration;
+
+	if (argc < 2)
+		return 1;
+
+	tpset = get_scan_type(&argc, &argv, &type);
+	if (tpset)
+		return tpset;
+
+	tpset = get_option_value(&argc, &argv, "page", &page, &valid_page);
+	if (tpset)
+		return tpset;
+	if (valid_page && page > UINT8_MAX)
+		return 1;
+
+	tpset = get_option_value(&argc, &argv, "channels", &channels, &valid_channels);
+	if (tpset)
+		return tpset;
+	if (valid_channels && channels > UINT32_MAX)
+		return 1;
+
+	tpset = get_option_value(&argc, &argv, "duration", &duration, &valid_duration);
+	if (tpset)
+		return tpset;
+	if (valid_duration && duration > UINT8_MAX)
+		return 1;
+
+	if (argc)
+		return 1;
+
+	/* Mandatory argument */
+	NLA_PUT_U8(msg, NL802154_ATTR_SCAN_TYPE, type);
+	/* Optional arguments */
+	if (valid_duration)
+		NLA_PUT_U8(msg, NL802154_ATTR_SCAN_DURATION, duration);
+	if (valid_page)
+		NLA_PUT_U8(msg, NL802154_ATTR_PAGE, page);
+	if (valid_channels)
+		NLA_PUT_U32(msg, NL802154_ATTR_SCAN_CHANNELS, channels);
+
+	/* TODO: support IES parameters for active scans */
+
+	return 0;
+
+nla_put_failure:
+	return -ENOBUFS;
+}
+
+static int scan_abort_handler(struct nl802154_state *state,
+			      struct nl_cb *cb,
+			      struct nl_msg *msg,
+			      int argc, char **argv,
+			      enum id_input id)
+{
+	return 0;
+}
+
+
+static int parse_new_coordinator(struct nlattr *nestedcoord,
+				 struct nlattr *ifattr)
+{
+	struct nlattr *pan[NL802154_COORD_MAX + 1];
+	static struct nla_policy pan_policy[NL802154_COORD_MAX + 1] = {
+		[NL802154_COORD_PANID] = { .type = NLA_U16, },
+		[NL802154_COORD_ADDR] = { .minlen = 2, .maxlen = 8, }, /* 2 or 8 */
+		[NL802154_COORD_CHANNEL] = { .type = NLA_U8, },
+		[NL802154_COORD_PAGE] = { .type = NLA_U8, },
+		[NL802154_COORD_PREAMBLE_CODE] = { .type = NLA_U8, },
+		[NL802154_COORD_MEAN_PRF] = { .type = NLA_U8, },
+		[NL802154_COORD_SUPERFRAME_SPEC] = { .type = NLA_U16, },
+		[NL802154_COORD_LINK_QUALITY] = { .type = NLA_U8, },
+		[NL802154_COORD_GTS_PERMIT] = { .type = NLA_FLAG, },
+	};
+	char dev[20];
+	int ret;
+
+	ret = nla_parse_nested(pan, NL802154_COORD_MAX, nestedcoord, pan_policy);
+	if (ret < 0) {
+		fprintf(stderr, "failed to parse nested attributes! (ret = %d)\n",
+			ret);
+		return NL_SKIP;
+	}
+	if (!pan[NL802154_COORD_PANID])
+		return NL_SKIP;
+
+	printf("PAN 0x%04x", le16toh(nla_get_u16(pan[NL802154_COORD_PANID])));
+	if (ifattr) {
+		if_indextoname(nla_get_u32(ifattr), dev);
+		printf(" (on %s)", dev);
+	}
+	printf("\n");
+	if (pan[NL802154_COORD_ADDR]) {
+		struct nlattr *coord = pan[NL802154_COORD_ADDR];
+		if (nla_len(coord) == 2) {
+			uint16_t addr = nla_get_u16(coord);
+			printf("\tcoordinator 0x%04x\n", le16toh(addr));
+		} else {
+			uint64_t addr = nla_get_u64(coord);
+			printf("\tcoordinator 0x%016" PRIx64 "\n", le64toh(addr));
+		}
+	}
+	if (pan[NL802154_COORD_PAGE]) {
+		printf("\tpage %u\n", nla_get_u8(pan[NL802154_COORD_PAGE]));
+	}
+	if (pan[NL802154_COORD_CHANNEL]) {
+		printf("\tchannel %u\n", nla_get_u8(pan[NL802154_COORD_CHANNEL]));
+	}
+	if (pan[NL802154_COORD_SUPERFRAME_SPEC]) {
+		printf("\tsuperframe spec. 0x%x\n", nla_get_u16(
+				pan[NL802154_COORD_SUPERFRAME_SPEC]));
+	}
+	if (pan[NL802154_COORD_LINK_QUALITY]) {
+		printf("\tLQI %x\n", nla_get_u8(
+				pan[NL802154_COORD_LINK_QUALITY]));
+	}
+	if (pan[NL802154_COORD_GTS_PERMIT]) {
+		printf("\tGTS permitted\n");
+	}
+
+	/* TODO: Beacon IES display/decoding */
+
+	return NL_OK;
+}
+
+static int print_new_coordinator_handler(struct nl_msg *msg, void *arg)
+{
+	struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+	struct nlattr *tb[NL802154_ATTR_MAX + 1];
+	struct nlattr *nestedcoord;
+
+	nla_parse(tb, NL802154_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+		  genlmsg_attrlen(gnlh, 0), NULL);
+
+	nestedcoord = tb[NL802154_ATTR_COORDINATOR];
+	if (!nestedcoord) {
+		fprintf(stderr, "coordinator info missing!\n");
+		return NL_SKIP;
+	}
+
+	return parse_new_coordinator(nestedcoord, tb[NL802154_ATTR_IFINDEX]);
+}
+
+struct scan_done
+{
+	volatile int done;
+	int devidx;
+};
+
+static int wait_scan_done_handler(struct nl_msg *msg, void *arg)
+{
+	struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+	struct scan_done *sd = (struct scan_done *)arg;
+
+	if (gnlh->cmd == NL802154_CMD_NEW_COORDINATOR)
+		return print_new_coordinator_handler(msg, arg);
+
+	if (gnlh->cmd != NL802154_CMD_SCAN_DONE)
+		return 0;
+
+	if (sd->devidx != -1) {
+		struct nlattr *tb[NL802154_ATTR_MAX + 1];
+		nla_parse(tb, NL802154_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+			genlmsg_attrlen(gnlh, 0), NULL);
+		if (!tb[NL802154_ATTR_IFINDEX] ||
+			nla_get_u32(tb[NL802154_ATTR_IFINDEX]) != sd->devidx)
+			return 0;
+	}
+
+	sd->done = 1;
+	return 0;
+}
+
+static int no_seq_check(struct nl_msg *msg, void *arg)
+{
+	return NL_OK;
+}
+
+static int scan_done_handler(struct nl802154_state *state,
+			     struct nl_cb *cb,
+			     struct nl_msg *msg,
+			     int argc, char **argv,
+			     enum id_input id)
+{
+	struct nl_cb *s_cb;
+	struct scan_done sd;
+	int ret, group;
+
+	/* Configure socket to receive messages in Scan multicast group */
+	group = genl_ctrl_resolve_grp(state->nl_sock, "nl802154", "scan");
+	if (group < 0)
+		return group;
+	ret = nl_socket_add_membership(state->nl_sock, group);
+	if (ret)
+		return ret;
+	/* Init netlink callbacks as if we run a command */
+	cb = nl_cb_alloc(iwpan_debug ? NL_CB_DEBUG : NL_CB_DEFAULT);
+	if (!cb) {
+		fprintf(stderr, "failed to allocate netlink callbacks\n");
+		return 2;
+	}
+	nl_socket_set_cb(state->nl_sock, cb);
+	/* no sequence checking for multicast messages */
+	nl_socket_disable_seq_check(state->nl_sock);
+	/* install scan done message handler */
+	nl_cb_set(cb, NL_CB_VALID, NL_CB_CUSTOM, wait_scan_done_handler, &sd);
+	/* set net device filter */
+	sd.devidx = if_nametoindex(*argv);
+	if (sd.devidx == 0)
+		sd.devidx = -1;
+	sd.done = 0;
+	/* loop waiting */
+	while (sd.done == 0)
+		nl_recvmsgs(state->nl_sock, cb);
+	/* restore seq & leave multicast group */
+	ret = nl_socket_drop_membership(state->nl_sock, group);
+	nl_cb_put(cb);
+	return ret;
+}
+
+static int scan_combined_handler(struct nl802154_state *state,
+				 struct nl_cb *cb,
+				 struct nl_msg *msg,
+				 int argc, char **argv,
+				 enum id_input id)
+{
+	char **trig_argv;
+	static char *show_argv[] = {
+		NULL,
+		"scan",
+		"done",
+	};
+	int trig_argc, err;
+	int i;
+
+	/* dev wpan0 scan trigger ... */
+	trig_argc = 3 + (argc - 2);
+	trig_argv = calloc(trig_argc, sizeof(*trig_argv));
+	if (!trig_argv)
+		return -ENOMEM;
+	trig_argv[0] = argv[0];
+	trig_argv[1] = "scan";
+	trig_argv[2] = "trigger";
+	for (i = 0; i < argc - 2; i++)
+		trig_argv[i + 3] = argv[i + 2];
+	err = handle_cmd(state, id, trig_argc, trig_argv);
+	free(trig_argv);
+	if (err)
+		return err;
+
+	/* dev wpanX scan show */
+	show_argv[0] = argv[0];
+	return handle_cmd(state, id, 3, show_argv);
+}
+TOPLEVEL(scan, "type <type> [page <page>] [channels <bitfield>] [duration <duration-order>]",
+	0, 0, CIB_NETDEV, scan_combined_handler,
+	"Scan on this virtual interface with the given configuration.\n"
+	SCAN_TYPES);
+COMMAND(scan, abort, NULL, NL802154_CMD_ABORT_SCAN, 0, CIB_NETDEV, scan_abort_handler,
+	"Abort ongoing scanning on this virtual interface");
+COMMAND(scan, done, NULL, 0, 0, CIB_NETDEV, scan_done_handler,
+	"Wait the scan operation to finish on this virtual interface, showing discoveries");
+COMMAND(scan, trigger,
+	"type <type> [page <page>] [channels <bitfield>] [duration <duration-order>]",
+	NL802154_CMD_TRIGGER_SCAN, 0, CIB_NETDEV, scan_trigger_handler,
+	"Launch scanning on this virtual interface with the given configuration.\n"
+	SCAN_TYPES);
+
+SECTION(beacons);
+
+static int send_beacons_handler(struct nl802154_state *state, struct nl_cb *cb,
+				struct nl_msg *msg, int argc, char **argv,
+				enum id_input id)
+{
+	unsigned long interval;
+	bool valid_interval;
+	int tpset;
+
+	tpset = get_option_value(&argc, &argv, "interval", &interval, &valid_interval);
+	if (tpset)
+		return tpset;
+	if (valid_interval && interval > UINT8_MAX)
+		return 1;
+
+	if (argc)
+		return 1;
+
+	/* Optional arguments */
+	if (valid_interval)
+		NLA_PUT_U8(msg, NL802154_ATTR_BEACON_INTERVAL, interval);
+
+	return 0;
+
+nla_put_failure:
+	return -ENOBUFS;
+}
+
+static int stop_beacons_handler(struct nl802154_state *state, struct nl_cb *cb,
+				struct nl_msg *msg, int argc, char **argv,
+				enum id_input id)
+{
+	return 0;
+}
+
+COMMAND(beacons, stop, NULL,
+	NL802154_CMD_STOP_BEACONS, 0, CIB_NETDEV, stop_beacons_handler,
+	"Stop sending beacons on this interface.");
+COMMAND(beacons, send, "[interval <interval-order>]",
+	NL802154_CMD_SEND_BEACONS, 0, CIB_NETDEV, send_beacons_handler,
+	"Send beacons on this virtual interface at a regular pace.");
-- 
2.34.1

[PATCH wpan-tools 7/7] iwpan: Add events support

[Miquel Raynal]

From: David Girault <david.girault@qorvo.com>

Add the possibility to listen to the scan multicast netlink family in
order to print all the events happening in the 802.15.4 stack, like the
discovery of a new coordinator or an end of scan.

Signed-off-by: David Girault <david.girault@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 src/Makefile.am |   1 +
 src/event.c     | 222 ++++++++++++++++++++++++++++++++++++++++++++++++
 src/iwpan.h     |   3 +
 src/scan.c      |   5 +-
 4 files changed, 228 insertions(+), 3 deletions(-)
 create mode 100644 src/event.c

diff --git a/src/Makefile.am b/src/Makefile.am
index 18b3569..7933daf 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -10,6 +10,7 @@ iwpan_SOURCES = \
 	phy.c \
 	mac.c \
 	scan.c \
+	event.c \
 	nl_extras.h \
 	nl802154.h
 
diff --git a/src/event.c b/src/event.c
new file mode 100644
index 0000000..2eab144
--- /dev/null
+++ b/src/event.c
@@ -0,0 +1,222 @@
+#include <net/if.h>
+#include <errno.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <inttypes.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl802154.h"
+#include "nl_extras.h"
+#include "iwpan.h"
+
+struct print_event_args {
+	struct timeval ts; /* internal */
+	bool have_ts; /* must be set false */
+	bool frame, time, reltime;
+};
+
+static void parse_scan_terminated(struct nlattr **tb)
+{
+	struct nlattr *a;
+	if ((a = tb[NL802154_ATTR_SCAN_TYPE])) {
+		enum nl802154_scan_types st =
+			(enum nl802154_scan_types)nla_get_u8(a);
+		const char *stn = scantype_name(st);
+		printf(" type %s,", stn);
+	}
+	if ((a = tb[NL802154_ATTR_SCAN_FLAGS])) {
+		printf(" flags 0x%x,", nla_get_u32(a));
+	}
+	if ((a = tb[NL802154_ATTR_PAGE])) {
+		printf(" page %u,", nla_get_u8(a));
+	}
+	if ((a = tb[NL802154_ATTR_SCAN_CHANNELS])) {
+		printf(" channels mask 0x%x,", nla_get_u32(a));
+	}
+	/* TODO: show requested IEs */
+	if ((a = tb[NL802154_ATTR_COORDINATOR])) {
+		parse_scan_result_pan(a, tb[NL802154_ATTR_IFINDEX]);
+	}
+}
+
+static int print_event(struct nl_msg *msg, void *arg)
+{
+	struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+	struct nlattr *tb[NL802154_ATTR_MAX + 1], *nst;
+	struct print_event_args *args = arg;
+	char ifname[100];
+
+	uint8_t reg_type;
+	uint32_t wpan_phy_idx = 0;
+	int rem_nst;
+	uint16_t status;
+
+	if (args->time || args->reltime) {
+		unsigned long long usecs, previous;
+
+		previous = 1000000ULL * args->ts.tv_sec + args->ts.tv_usec;
+		gettimeofday(&args->ts, NULL);
+		usecs = 1000000ULL * args->ts.tv_sec + args->ts.tv_usec;
+		if (args->reltime) {
+			if (!args->have_ts) {
+				usecs = 0;
+				args->have_ts = true;
+			} else
+				usecs -= previous;
+		}
+		printf("%llu.%06llu: ", usecs/1000000, usecs % 1000000);
+	}
+
+	nla_parse(tb, NL802154_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+		  genlmsg_attrlen(gnlh, 0), NULL);
+
+	if (tb[NL802154_ATTR_IFINDEX] && tb[NL802154_ATTR_WPAN_PHY]) {
+		if_indextoname(nla_get_u32(tb[NL802154_ATTR_IFINDEX]), ifname);
+		printf("%s (phy #%d): ", ifname, nla_get_u32(tb[NL802154_ATTR_WPAN_PHY]));
+	} else if (tb[NL802154_ATTR_WPAN_DEV] && tb[NL802154_ATTR_WPAN_PHY]) {
+		printf("wdev 0x%llx (phy #%d): ",
+			(unsigned long long)nla_get_u64(tb[NL802154_ATTR_WPAN_DEV]),
+			nla_get_u32(tb[NL802154_ATTR_WPAN_PHY]));
+	} else if (tb[NL802154_ATTR_IFINDEX]) {
+		if_indextoname(nla_get_u32(tb[NL802154_ATTR_IFINDEX]), ifname);
+		printf("%s: ", ifname);
+	} else if (tb[NL802154_ATTR_WPAN_DEV]) {
+		printf("wdev 0x%llx: ", (unsigned long long)nla_get_u64(tb[NL802154_ATTR_WPAN_DEV]));
+	} else if (tb[NL802154_ATTR_WPAN_PHY]) {
+		printf("phy #%d: ", nla_get_u32(tb[NL802154_ATTR_WPAN_PHY]));
+	}
+
+	switch (gnlh->cmd) {
+	case NL802154_CMD_NEW_WPAN_PHY:
+		printf("renamed to %s\n", nla_get_string(tb[NL802154_ATTR_WPAN_PHY_NAME]));
+		break;
+	case NL802154_CMD_DEL_WPAN_PHY:
+		printf("delete wpan_phy\n");
+		break;
+	case NL802154_CMD_TRIGGER_SCAN:
+		printf("scan started\n");
+		break;
+	case NL802154_CMD_SCAN_DONE:
+		printf("scan finished\n");
+		break;
+	case NL802154_CMD_NEW_COORDINATOR:
+		printf("new coordinator\n");
+		break;
+	default:
+		printf("unknown event %d\n", gnlh->cmd);
+		break;
+	}
+	fflush(stdout);
+	return NL_SKIP;
+}
+
+static int __prepare_listen_events(struct nl802154_state *state)
+{
+	int mcid, ret;
+
+	/* Configuration multicast group */
+	mcid = genl_ctrl_resolve_grp(state->nl_sock, NL802154_GENL_NAME,
+				     "config");
+	if (mcid < 0)
+		return mcid;
+	ret = nl_socket_add_membership(state->nl_sock, mcid);
+	if (ret)
+		return ret;
+
+	/* Scan multicast group */
+	mcid = genl_ctrl_resolve_grp(state->nl_sock, NL802154_GENL_NAME,
+				     "scan");
+	if (mcid >= 0) {
+		ret = nl_socket_add_membership(state->nl_sock, mcid);
+		if (ret)
+			return ret;
+	}
+
+	/* MLME multicast group */
+	mcid = genl_ctrl_resolve_grp(state->nl_sock, NL802154_GENL_NAME,
+				     "mlme");
+	if (mcid >= 0) {
+		ret = nl_socket_add_membership(state->nl_sock, mcid);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int __do_listen_events(struct nl802154_state *state,
+			      struct print_event_args *args)
+{
+	struct nl_cb *cb = nl_cb_alloc(iwpan_debug ? NL_CB_DEBUG : NL_CB_DEFAULT);
+	if (!cb) {
+		fprintf(stderr, "failed to allocate netlink callbacks\n");
+		return -ENOMEM;
+	}
+	nl_socket_set_cb(state->nl_sock, cb);
+	/* No sequence checking for multicast messages */
+	nl_socket_disable_seq_check(state->nl_sock);
+	/* Install print_event message handler */
+	nl_cb_set(cb, NL_CB_VALID, NL_CB_CUSTOM, print_event, args);
+
+	/* Loop waiting until interrupted by signal */
+	while (1) {
+		int ret = nl_recvmsgs(state->nl_sock, cb);
+		if (ret) {
+			fprintf(stderr, "nl_recvmsgs return error %d\n", ret);
+			break;
+		}
+	}
+	/* Free allocated nl_cb structure */
+	nl_cb_put(cb);
+	return 0;
+}
+
+static int print_events(struct nl802154_state *state,
+			struct nl_cb *cb,
+			struct nl_msg *msg,
+			int argc, char **argv,
+			enum id_input id)
+{
+	struct print_event_args args;
+	int ret;
+
+	memset(&args, 0, sizeof(args));
+
+	argc--;
+	argv++;
+
+	while (argc > 0) {
+		if (strcmp(argv[0], "-f") == 0)
+			args.frame = true;
+		else if (strcmp(argv[0], "-t") == 0)
+			args.time = true;
+		else if (strcmp(argv[0], "-r") == 0)
+			args.reltime = true;
+		else
+			return 1;
+		argc--;
+		argv++;
+	}
+	if (args.time && args.reltime)
+		return 1;
+	if (argc)
+		return 1;
+
+	/* Prepare reception of all multicast messages */
+	ret = __prepare_listen_events(state);
+	if (ret)
+		return ret;
+
+	/* Read message loop */
+	return __do_listen_events(state, &args);
+}
+TOPLEVEL(event, "[-t|-r] [-f]", 0, 0, CIB_NONE, print_events,
+	"Monitor events from the kernel.\n"
+	"-t - print timestamp\n"
+	"-r - print relative timestamp\n"
+	"-f - print full frame for auth/assoc etc.");
diff --git a/src/iwpan.h b/src/iwpan.h
index 406940a..a71b991 100644
--- a/src/iwpan.h
+++ b/src/iwpan.h
@@ -114,6 +114,9 @@ DECLARE_SECTION(get);
 
 const char *iftype_name(enum nl802154_iftype iftype);
 
+const char *scantype_name(enum nl802154_scan_types scantype);
+int parse_scan_result_pan(struct nlattr *nestedpan, struct nlattr *ifattr);
+
 extern int iwpan_debug;
 
 #endif /* __IWPAN_H */
diff --git a/src/scan.c b/src/scan.c
index de6caf4..bc06069 100644
--- a/src/scan.c
+++ b/src/scan.c
@@ -16,7 +16,7 @@
 
 static char scantypebuf[100];
 
-static const char *scantype_name(enum nl802154_scan_types scantype)
+const char *scantype_name(enum nl802154_scan_types scantype)
 {
 	switch (scantype) {
 	case NL802154_SCAN_ED:
@@ -168,8 +168,7 @@ static int scan_abort_handler(struct nl802154_state *state,
 }
 
 
-static int parse_new_coordinator(struct nlattr *nestedcoord,
-				 struct nlattr *ifattr)
+int parse_new_coordinator(struct nlattr *nestedcoord, struct nlattr *ifattr)
 {
 	struct nlattr *pan[NL802154_COORD_MAX + 1];
 	static struct nla_policy pan_policy[NL802154_COORD_MAX + 1] = {
-- 
2.34.1

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hello,
>
> This series follows the work done in the Linux kernel stack: now that
> the core knows about the different netlink commands and attributes in
> order to support scanning and beaconing requests from end-to-end, here
> are the userspace changes to be able to use it.
>
> Here is a list of the new available features.
>
> * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
>   valid for passively sending beacons at regular intervals. An interval
>   of 15 would request the core to answer BEACON_REQ.
>   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
>   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
>   # iwpan dev coord0 beacons stop # apply to both cases
>
> * Scanning all the channels or only a subset:
>   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
>   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
>
> * During scans, there is a dedicated netlink channel event to listen to
>   in order to get events like "a new coordinator was discovered" or "the
>   scan is over". When beacons from new devices are received, the tool
>   would print something like:
>   PAN 0xabcd (on coord1)
>         coordinator 0xe673d7a3f3a87ccc
>         page 0
>         channel 13
>         preamble code 0
>         mean prf 0
>         superframe spec. 0x4f11
>         LQI 0
>
> * It is also possible to monitor the events with:
>   # iwpan event
>
> * As well as triggering a non blocking scan:
>   # iwpan dev wpan1 scan trigger type passive duration 3
>   # iwpan dev wpan1 scan done
>   # iwpan dev wpan1 scan abort

why do we need an abort?

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Sun, Jul 3, 2022 at 9:18 PM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hello,
> >
> > This series follows the work done in the Linux kernel stack: now that
> > the core knows about the different netlink commands and attributes in
> > order to support scanning and beaconing requests from end-to-end, here
> > are the userspace changes to be able to use it.
> >
> > Here is a list of the new available features.
> >
> > * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
> >   valid for passively sending beacons at regular intervals. An interval
> >   of 15 would request the core to answer BEACON_REQ.
> >   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
> >   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
> >   # iwpan dev coord0 beacons stop # apply to both cases
> >
> > * Scanning all the channels or only a subset:
> >   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
> >   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
> >
> > * During scans, there is a dedicated netlink channel event to listen to
> >   in order to get events like "a new coordinator was discovered" or "the
> >   scan is over". When beacons from new devices are received, the tool
> >   would print something like:
> >   PAN 0xabcd (on coord1)
> >         coordinator 0xe673d7a3f3a87ccc
> >         page 0
> >         channel 13
> >         preamble code 0
> >         mean prf 0
> >         superframe spec. 0x4f11
> >         LQI 0
> >
> > * It is also possible to monitor the events with:
> >   # iwpan event
> >
> > * As well as triggering a non blocking scan:
> >   # iwpan dev wpan1 scan trigger type passive duration 3
> >   # iwpan dev wpan1 scan done
> >   # iwpan dev wpan1 scan abort
>
> why do we need an abort?

I'm still thinking about it. Is done a kind of "block until scan is
done", but isn't this an event to signal when the mac operation is
done? What is the difference between done and abort, is this not just
"end" as I don't want to be in scan mode anymore (because we block all
interface traffic during this time)?

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400:

> Hi,
> 
> On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hello,
> >
> > This series follows the work done in the Linux kernel stack: now that
> > the core knows about the different netlink commands and attributes in
> > order to support scanning and beaconing requests from end-to-end, here
> > are the userspace changes to be able to use it.
> >
> > Here is a list of the new available features.
> >
> > * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
> >   valid for passively sending beacons at regular intervals. An interval
> >   of 15 would request the core to answer BEACON_REQ.
> >   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
> >   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
> >   # iwpan dev coord0 beacons stop # apply to both cases
> >
> > * Scanning all the channels or only a subset:
> >   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
> >   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
> >
> > * During scans, there is a dedicated netlink channel event to listen to
> >   in order to get events like "a new coordinator was discovered" or "the
> >   scan is over". When beacons from new devices are received, the tool
> >   would print something like:
> >   PAN 0xabcd (on coord1)
> >         coordinator 0xe673d7a3f3a87ccc
> >         page 0
> >         channel 13
> >         preamble code 0
> >         mean prf 0
> >         superframe spec. 0x4f11
> >         LQI 0
> >
> > * It is also possible to monitor the events with:
> >   # iwpan event
> >
> > * As well as triggering a non blocking scan:
> >   # iwpan dev wpan1 scan trigger type passive duration 3
> >   # iwpan dev wpan1 scan done
> >   # iwpan dev wpan1 scan abort  
> 
> why do we need an abort?

Perhaps the tool --help would have helped to get the naming, but we
need:
- a command to start a scan, either use:
  * "scan" alone and it is synchronous, I mean the command returns when
    the scan is over
  or
  * "scan trigger" which is asynchronous, and returns immediately after
    starting the operation
- if the scan was started asynchronously with the "trigger" keyword,
  the "done" command will wait until the scan is over (maybe this one
  needs to be renamed?)
- if the user made a mistake and do not want to remain blocked for
  several minutes (a scan can last for very long time), we need the
  "abort" command to tell the kernel to stop and return to a standard
  state. Once this has been processed and the scan effectively stopped,
  the kernel will send a nl command saying the scan is over (which
  "scan done" would capture)

Thanks,
Miquèl

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400:
>
> > Hi,
> >
> > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hello,
> > >
> > > This series follows the work done in the Linux kernel stack: now that
> > > the core knows about the different netlink commands and attributes in
> > > order to support scanning and beaconing requests from end-to-end, here
> > > are the userspace changes to be able to use it.
> > >
> > > Here is a list of the new available features.
> > >
> > > * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
> > >   valid for passively sending beacons at regular intervals. An interval
> > >   of 15 would request the core to answer BEACON_REQ.
> > >   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
> > >   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
> > >   # iwpan dev coord0 beacons stop # apply to both cases
> > >
> > > * Scanning all the channels or only a subset:
> > >   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
> > >   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
> > >
> > > * During scans, there is a dedicated netlink channel event to listen to
> > >   in order to get events like "a new coordinator was discovered" or "the
> > >   scan is over". When beacons from new devices are received, the tool
> > >   would print something like:
> > >   PAN 0xabcd (on coord1)
> > >         coordinator 0xe673d7a3f3a87ccc
> > >         page 0
> > >         channel 13
> > >         preamble code 0
> > >         mean prf 0
> > >         superframe spec. 0x4f11
> > >         LQI 0
> > >
> > > * It is also possible to monitor the events with:
> > >   # iwpan event
> > >
> > > * As well as triggering a non blocking scan:
> > >   # iwpan dev wpan1 scan trigger type passive duration 3
> > >   # iwpan dev wpan1 scan done
> > >   # iwpan dev wpan1 scan abort
> >
> > why do we need an abort?
>
> Perhaps the tool --help would have helped to get the naming, but we
> need:
> - a command to start a scan, either use:
>   * "scan" alone and it is synchronous, I mean the command returns when
>     the scan is over
>   or
>   * "scan trigger" which is asynchronous, and returns immediately after
>     starting the operation
> - if the scan was started asynchronously with the "trigger" keyword,
>   the "done" command will wait until the scan is over (maybe this one
>   needs to be renamed?)
> - if the user made a mistake and do not want to remain blocked for
>   several minutes (a scan can last for very long time), we need the
>   "abort" command to tell the kernel to stop and return to a standard
>   state. Once this has been processed and the scan effectively stopped,
>   the kernel will send a nl command saying the scan is over (which
>   "scan done" would capture)
>

For me, trigger and done should be for the simple cli use case in one
command like "scan list". It will block them and trigger any scan
event popping up. The user can send SIGINT to stop scanning?

Although there should be still available an asynchronous way which is
for me "scan trigger" (non-blocking) and the user can do "iwpan
monitor" to observe upcoming events (all inclusive scan) and tell
optionally "scan done" to stop scanning if necessary (which probably
also produces an event to notify all listeners e.g. iwpan monitor).

However I think most people using iwpan want to trigger and wait and
the cli is filling up events and blocks until it's done (that would be
a combination with trigger/monitor into one command).

Both solutions should be possible over cli?

Does this sound okay?

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Tue, 23 Aug 2022 21:36:23 -0400:

> Hi,
> 
> On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400:
> >  
> > > Hi,
> > >
> > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > Hello,
> > > >
> > > > This series follows the work done in the Linux kernel stack: now that
> > > > the core knows about the different netlink commands and attributes in
> > > > order to support scanning and beaconing requests from end-to-end, here
> > > > are the userspace changes to be able to use it.
> > > >
> > > > Here is a list of the new available features.
> > > >
> > > > * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
> > > >   valid for passively sending beacons at regular intervals. An interval
> > > >   of 15 would request the core to answer BEACON_REQ.
> > > >   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
> > > >   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
> > > >   # iwpan dev coord0 beacons stop # apply to both cases
> > > >
> > > > * Scanning all the channels or only a subset:
> > > >   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
> > > >   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
> > > >
> > > > * During scans, there is a dedicated netlink channel event to listen to
> > > >   in order to get events like "a new coordinator was discovered" or "the
> > > >   scan is over". When beacons from new devices are received, the tool
> > > >   would print something like:
> > > >   PAN 0xabcd (on coord1)
> > > >         coordinator 0xe673d7a3f3a87ccc
> > > >         page 0
> > > >         channel 13
> > > >         preamble code 0
> > > >         mean prf 0
> > > >         superframe spec. 0x4f11
> > > >         LQI 0
> > > >
> > > > * It is also possible to monitor the events with:
> > > >   # iwpan event
> > > >
> > > > * As well as triggering a non blocking scan:
> > > >   # iwpan dev wpan1 scan trigger type passive duration 3
> > > >   # iwpan dev wpan1 scan done
> > > >   # iwpan dev wpan1 scan abort  
> > >
> > > why do we need an abort?  
> >
> > Perhaps the tool --help would have helped to get the naming, but we
> > need:
> > - a command to start a scan, either use:
> >   * "scan" alone and it is synchronous, I mean the command returns when
> >     the scan is over
> >   or
> >   * "scan trigger" which is asynchronous, and returns immediately after
> >     starting the operation
> > - if the scan was started asynchronously with the "trigger" keyword,
> >   the "done" command will wait until the scan is over (maybe this one
> >   needs to be renamed?)
> > - if the user made a mistake and do not want to remain blocked for
> >   several minutes (a scan can last for very long time), we need the
> >   "abort" command to tell the kernel to stop and return to a standard
> >   state. Once this has been processed and the scan effectively stopped,
> >   the kernel will send a nl command saying the scan is over (which
> >   "scan done" would capture)
> >  
> 
> For me, trigger and done should be for the simple cli use case in one
> command like "scan list". It will block them and trigger any scan
> event popping up. The user can send SIGINT to stop scanning?
> 
> Although there should be still available an asynchronous way which is
> for me "scan trigger" (non-blocking) and the user can do "iwpan
> monitor" to observe upcoming events (all inclusive scan) and tell
> optionally "scan done" to stop scanning if necessary (which probably
> also produces an event to notify all listeners e.g. iwpan monitor).
> 
> However I think most people using iwpan want to trigger and wait and
> the cli is filling up events and blocks until it's done (that would be
> a combination with trigger/monitor into one command).
> 
> Both solutions should be possible over cli?

Yes, that's what I was saying, the two solutions are already supported.
The iwpan tool is being enhanced with the "scan" composite command,
- either "scan" is given an additional keyword and makes just that
  (trigger, abort, done) and returns as soon as this precise
  command is done (eg. it returns almost immediately on "trigger")
- or, no additional command is provided (only the parameters for the
  scan) and the command does an equivalent to "trigger + monitor +
  done" which blocks after launching the scan, shows the results when
  they arrive, and returns once the scan is finished.

Do you want something more? I just miss a "monitor" command I guess, I
may add it.

Thanks,
Miquèl

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Thu, Aug 25, 2022 at 8:55 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Tue, 23 Aug 2022 21:36:23 -0400:
>
> > Hi,
> >
> > On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Alexander,
> > >
> > > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400:
> > >
> > > > Hi,
> > > >
> > > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > This series follows the work done in the Linux kernel stack: now that
> > > > > the core knows about the different netlink commands and attributes in
> > > > > order to support scanning and beaconing requests from end-to-end, here
> > > > > are the userspace changes to be able to use it.
> > > > >
> > > > > Here is a list of the new available features.
> > > > >
> > > > > * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
> > > > >   valid for passively sending beacons at regular intervals. An interval
> > > > >   of 15 would request the core to answer BEACON_REQ.
> > > > >   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
> > > > >   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
> > > > >   # iwpan dev coord0 beacons stop # apply to both cases
> > > > >
> > > > > * Scanning all the channels or only a subset:
> > > > >   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
> > > > >   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
> > > > >
> > > > > * During scans, there is a dedicated netlink channel event to listen to
> > > > >   in order to get events like "a new coordinator was discovered" or "the
> > > > >   scan is over". When beacons from new devices are received, the tool
> > > > >   would print something like:
> > > > >   PAN 0xabcd (on coord1)
> > > > >         coordinator 0xe673d7a3f3a87ccc
> > > > >         page 0
> > > > >         channel 13
> > > > >         preamble code 0
> > > > >         mean prf 0
> > > > >         superframe spec. 0x4f11
> > > > >         LQI 0
> > > > >
> > > > > * It is also possible to monitor the events with:
> > > > >   # iwpan event
> > > > >
> > > > > * As well as triggering a non blocking scan:
> > > > >   # iwpan dev wpan1 scan trigger type passive duration 3
> > > > >   # iwpan dev wpan1 scan done
> > > > >   # iwpan dev wpan1 scan abort
> > > >
> > > > why do we need an abort?
> > >
> > > Perhaps the tool --help would have helped to get the naming, but we
> > > need:
> > > - a command to start a scan, either use:
> > >   * "scan" alone and it is synchronous, I mean the command returns when
> > >     the scan is over
> > >   or
> > >   * "scan trigger" which is asynchronous, and returns immediately after
> > >     starting the operation
> > > - if the scan was started asynchronously with the "trigger" keyword,
> > >   the "done" command will wait until the scan is over (maybe this one
> > >   needs to be renamed?)
> > > - if the user made a mistake and do not want to remain blocked for
> > >   several minutes (a scan can last for very long time), we need the
> > >   "abort" command to tell the kernel to stop and return to a standard
> > >   state. Once this has been processed and the scan effectively stopped,
> > >   the kernel will send a nl command saying the scan is over (which
> > >   "scan done" would capture)
> > >
> >
> > For me, trigger and done should be for the simple cli use case in one
> > command like "scan list". It will block them and trigger any scan
> > event popping up. The user can send SIGINT to stop scanning?
> >
> > Although there should be still available an asynchronous way which is
> > for me "scan trigger" (non-blocking) and the user can do "iwpan
> > monitor" to observe upcoming events (all inclusive scan) and tell
> > optionally "scan done" to stop scanning if necessary (which probably
> > also produces an event to notify all listeners e.g. iwpan monitor).
> >
> > However I think most people using iwpan want to trigger and wait and
> > the cli is filling up events and blocks until it's done (that would be
> > a combination with trigger/monitor into one command).
> >
> > Both solutions should be possible over cli?
>
> Yes, that's what I was saying, the two solutions are already supported.
> The iwpan tool is being enhanced with the "scan" composite command,
> - either "scan" is given an additional keyword and makes just that
>   (trigger, abort, done) and returns as soon as this precise
>   command is done (eg. it returns almost immediately on "trigger")

But why do we need to have a done command?

Sorry, I still don't get that.

> - or, no additional command is provided (only the parameters for the
>   scan) and the command does an equivalent to "trigger + monitor +
>   done" which blocks after launching the scan, shows the results when
>   they arrive, and returns once the scan is finished.

"trigger + monitor" there is no done command needed here or? The
process should unblock when it's done, and for SIGINT/SIGKILL send an
abort? Maybe a done event when the scan is "successful" finished and
everything that was there in the channel/page combinations was scanned
without an abort.

We need to consider that other processes listen to events? They should
be aware of what's happening there? There should be some event
sequence going on "trigger event" + "loop of found something event" +
"either abort or done"?

>
> Do you want something more? I just miss a "monitor" command I guess, I
> may add it.
>

Yea, monitor sounds like ip monitor, udevadm monitor, etc. to listen
to all those 802.15.4 subsystem events. I would take a look into it
for any scan results. At the end you should be able to do a blocked
scan and monitor at the same time and they should at least provide
similar events.
Probably the blocked scan with nicer output and filtered and the
monitor is for everything that is going on in 802.15.4 there.

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Thu, 25 Aug 2022 21:22:48 -0400:

> Hi,
> 
> On Thu, Aug 25, 2022 at 8:55 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Tue, 23 Aug 2022 21:36:23 -0400:
> >  
> > > Hi,
> > >
> > > On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > Hi Alexander,
> > > >
> > > > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400:
> > > >  
> > > > > Hi,
> > > > >
> > > > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > This series follows the work done in the Linux kernel stack: now that
> > > > > > the core knows about the different netlink commands and attributes in
> > > > > > order to support scanning and beaconing requests from end-to-end, here
> > > > > > are the userspace changes to be able to use it.
> > > > > >
> > > > > > Here is a list of the new available features.
> > > > > >
> > > > > > * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
> > > > > >   valid for passively sending beacons at regular intervals. An interval
> > > > > >   of 15 would request the core to answer BEACON_REQ.
> > > > > >   # iwpan dev coord0 beacons send interval 2 # send BEACON at a fixed rate
> > > > > >   # iwpan dev coord0 beacons send interval 15 # answer BEACON_REQ only
> > > > > >   # iwpan dev coord0 beacons stop # apply to both cases
> > > > > >
> > > > > > * Scanning all the channels or only a subset:
> > > > > >   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
> > > > > >   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
> > > > > >
> > > > > > * During scans, there is a dedicated netlink channel event to listen to
> > > > > >   in order to get events like "a new coordinator was discovered" or "the
> > > > > >   scan is over". When beacons from new devices are received, the tool
> > > > > >   would print something like:
> > > > > >   PAN 0xabcd (on coord1)
> > > > > >         coordinator 0xe673d7a3f3a87ccc
> > > > > >         page 0
> > > > > >         channel 13
> > > > > >         preamble code 0
> > > > > >         mean prf 0
> > > > > >         superframe spec. 0x4f11
> > > > > >         LQI 0
> > > > > >
> > > > > > * It is also possible to monitor the events with:
> > > > > >   # iwpan event
> > > > > >
> > > > > > * As well as triggering a non blocking scan:
> > > > > >   # iwpan dev wpan1 scan trigger type passive duration 3
> > > > > >   # iwpan dev wpan1 scan done
> > > > > >   # iwpan dev wpan1 scan abort  
> > > > >
> > > > > why do we need an abort?  
> > > >
> > > > Perhaps the tool --help would have helped to get the naming, but we
> > > > need:
> > > > - a command to start a scan, either use:
> > > >   * "scan" alone and it is synchronous, I mean the command returns when
> > > >     the scan is over
> > > >   or
> > > >   * "scan trigger" which is asynchronous, and returns immediately after
> > > >     starting the operation
> > > > - if the scan was started asynchronously with the "trigger" keyword,
> > > >   the "done" command will wait until the scan is over (maybe this one
> > > >   needs to be renamed?)
> > > > - if the user made a mistake and do not want to remain blocked for
> > > >   several minutes (a scan can last for very long time), we need the
> > > >   "abort" command to tell the kernel to stop and return to a standard
> > > >   state. Once this has been processed and the scan effectively stopped,
> > > >   the kernel will send a nl command saying the scan is over (which
> > > >   "scan done" would capture)
> > > >  
> > >
> > > For me, trigger and done should be for the simple cli use case in one
> > > command like "scan list". It will block them and trigger any scan
> > > event popping up. The user can send SIGINT to stop scanning?
> > >
> > > Although there should be still available an asynchronous way which is
> > > for me "scan trigger" (non-blocking) and the user can do "iwpan
> > > monitor" to observe upcoming events (all inclusive scan) and tell
> > > optionally "scan done" to stop scanning if necessary (which probably
> > > also produces an event to notify all listeners e.g. iwpan monitor).
> > >
> > > However I think most people using iwpan want to trigger and wait and
> > > the cli is filling up events and blocks until it's done (that would be
> > > a combination with trigger/monitor into one command).
> > >
> > > Both solutions should be possible over cli?  
> >
> > Yes, that's what I was saying, the two solutions are already supported.
> > The iwpan tool is being enhanced with the "scan" composite command,
> > - either "scan" is given an additional keyword and makes just that
> >   (trigger, abort, done) and returns as soon as this precise
> >   command is done (eg. it returns almost immediately on "trigger")  
> 
> But why do we need to have a done command?
> 
> Sorry, I still don't get that.

My bad, I changed the command and I forgot to update my draft.

> > - or, no additional command is provided (only the parameters for the
> >   scan) and the command does an equivalent to "trigger + monitor +
> >   done" which blocks after launching the scan, shows the results when
> >   they arrive, and returns once the scan is finished.  
> 
> "trigger + monitor" there is no done command needed here or? The
> process should unblock when it's done, and for SIGINT/SIGKILL send an
> abort?

> Maybe a done event when the scan is "successful" finished and
> everything that was there in the channel/page combinations was scanned
> without an abort.
> 
> We need to consider that other processes listen to events? They should
> be aware of what's happening there? There should be some event
> sequence going on "trigger event" + "loop of found something event" +
> "either abort or done"?
> 
> >
> > Do you want something more? I just miss a "monitor" command I guess, I
> > may add it.
> >  
> 
> Yea, monitor sounds like ip monitor, udevadm monitor, etc. to listen
> to all those 802.15.4 subsystem events. I would take a look into it
> for any scan results. At the end you should be able to do a blocked
> scan and monitor at the same time and they should at least provide
> similar events.
> Probably the blocked scan with nicer output and filtered and the
> monitor is for everything that is going on in 802.15.4 there.

I've updated the tools so that we have:

* "scan trigger" which does not block
* "scan monitor" which displays with a pretty output the new
  coordinators and stops blocking when the scan is over (either because
  it reached the last channel to scan, or it got aborted)
* "scan abort" which stops an ongoing scan
* "scan" which is the same as "scan trigger; scan monitor", and will
  send an abort command if interrupted with SIGINT

On the other side there was in the previous versions a command "iwpan
event" which I just renamed "iwpan monitor" which follows anything
802154 related and displays a single line each time, it looks like:
# iwpan monitor -t // -t is an option to display timestamps
1661510897.820505: coord1 (phy #1): scan started
1661510903.874055: coord1 (phy #1): new coordinator detected: PAN 0xabcd, addr 0x42aab7e343ea5c0f
1661510908.953874: coord1 (phy #1): scan finished
1661510915.437030: coord1 (phy #1): scan started
1661510916.242412: coord1 (phy #1): scan aborted

This should address all the needs.

Thanks,
Miquèl

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
...
>
> I've updated the tools so that we have:
>
> * "scan trigger" which does not block
> * "scan monitor" which displays with a pretty output the new
>   coordinators and stops blocking when the scan is over (either because
>   it reached the last channel to scan, or it got aborted)
> * "scan abort" which stops an ongoing scan
> * "scan" which is the same as "scan trigger; scan monitor", and will

no, there is a race in the design of "scan trigger; scan monitor".

>   send an abort command if interrupted with SIGINT
>
> On the other side there was in the previous versions a command "iwpan
> event" which I just renamed "iwpan monitor" which follows anything
> 802154 related and displays a single line each time, it looks like:
> # iwpan monitor -t // -t is an option to display timestamps
> 1661510897.820505: coord1 (phy #1): scan started
> 1661510903.874055: coord1 (phy #1): new coordinator detected: PAN 0xabcd, addr 0x42aab7e343ea5c0f
> 1661510908.953874: coord1 (phy #1): scan finished
> 1661510915.437030: coord1 (phy #1): scan started
> 1661510916.242412: coord1 (phy #1): scan aborted
>
> This should address all the needs.

I would remove the scan monitor and if it is needed a "monitor scan",
"monitor" will give you all 802.15.4 events, scan will give you a
filter for all scan events and may we add in future even a ?phy/dev?
argument to filter per interface? :)

"monitor scan" just to move event monitoring to the right command.

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400:

> Hi,
> 
> On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> ...
> >
> > I've updated the tools so that we have:
> >
> > * "scan trigger" which does not block
> > * "scan monitor" which displays with a pretty output the new
> >   coordinators and stops blocking when the scan is over (either because
> >   it reached the last channel to scan, or it got aborted)
> > * "scan abort" which stops an ongoing scan
> > * "scan" which is the same as "scan trigger; scan monitor", and will  
> 
> no, there is a race in the design of "scan trigger; scan monitor".

Right, I've used pthread to first start the monitoring, before actually
triggering the scan. That should be enough.

> >   send an abort command if interrupted with SIGINT
> >
> > On the other side there was in the previous versions a command "iwpan
> > event" which I just renamed "iwpan monitor" which follows anything
> > 802154 related and displays a single line each time, it looks like:
> > # iwpan monitor -t // -t is an option to display timestamps
> > 1661510897.820505: coord1 (phy #1): scan started
> > 1661510903.874055: coord1 (phy #1): new coordinator detected: PAN 0xabcd, addr 0x42aab7e343ea5c0f
> > 1661510908.953874: coord1 (phy #1): scan finished
> > 1661510915.437030: coord1 (phy #1): scan started
> > 1661510916.242412: coord1 (phy #1): scan aborted
> >
> > This should address all the needs.  
> 
> I would remove the scan monitor and if it is needed a "monitor scan",

Actually we need both "scan monitor" and "monitor scan". The former
shows what is happening in a clean manner, with a detailed view of all
the information about the beacon received, while the latter would more
something that we run aside to follow what's happening, it's a bare and
short output (one-liners).

> "monitor" will give you all 802.15.4 events, scan will give you a
> filter for all scan events and may we add in future even a ?phy/dev?
> argument to filter per interface? :)
> 
> "monitor scan" just to move event monitoring to the right command.

I haven't added the "scan" option because we currently have almost only
that, it can be added later, it's just a tool to show how everything
works and give a code base anyway.

Thanks,
Miquèl

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400:
>
> > Hi,
> >
> > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > ...
> > >
> > > I've updated the tools so that we have:
> > >
> > > * "scan trigger" which does not block
> > > * "scan monitor" which displays with a pretty output the new
> > >   coordinators and stops blocking when the scan is over (either because
> > >   it reached the last channel to scan, or it got aborted)
> > > * "scan abort" which stops an ongoing scan
> > > * "scan" which is the same as "scan trigger; scan monitor", and will
> >
> > no, there is a race in the design of "scan trigger; scan monitor".
>
> Right, I've used pthread to first start the monitoring, before actually
> triggering the scan. That should be enough.
>

I think we should look at this, because it requires that all
applications link to pthreads if we offer such an API. Any thoughts
about alternative ways, can it not be done over libnl, that libnl
internally used e.g. select()? The above example is only regarding the
process context.

> > >   send an abort command if interrupted with SIGINT
> > >
> > > On the other side there was in the previous versions a command "iwpan
> > > event" which I just renamed "iwpan monitor" which follows anything
> > > 802154 related and displays a single line each time, it looks like:
> > > # iwpan monitor -t // -t is an option to display timestamps
> > > 1661510897.820505: coord1 (phy #1): scan started
> > > 1661510903.874055: coord1 (phy #1): new coordinator detected: PAN 0xabcd, addr 0x42aab7e343ea5c0f
> > > 1661510908.953874: coord1 (phy #1): scan finished
> > > 1661510915.437030: coord1 (phy #1): scan started
> > > 1661510916.242412: coord1 (phy #1): scan aborted
> > >
> > > This should address all the needs.
> >
> > I would remove the scan monitor and if it is needed a "monitor scan",
>
> Actually we need both "scan monitor" and "monitor scan". The former
> shows what is happening in a clean manner, with a detailed view of all
> the information about the beacon received, while the latter would more
> something that we run aside to follow what's happening, it's a bare and
> short output (one-liners).
>

For me that can be already provided by the iwpan monitor command,
maybe with some pretty print args or json args to have it in a nice
way or json whatever looks like ip/iw thingy. :)

However I don't really bother here, except that it might confuse
people who want to scan and probably want the blocked command only and
think the other scan commands are necessary to perform a scan...

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Alexander Aring]

Hi,

On Mon, Aug 29, 2022 at 8:57 AM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400:
> >
> > > Hi,
> > >
> > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > ...
> > > >
> > > > I've updated the tools so that we have:
> > > >
> > > > * "scan trigger" which does not block
> > > > * "scan monitor" which displays with a pretty output the new
> > > >   coordinators and stops blocking when the scan is over (either because
> > > >   it reached the last channel to scan, or it got aborted)
> > > > * "scan abort" which stops an ongoing scan
> > > > * "scan" which is the same as "scan trigger; scan monitor", and will
> > >
> > > no, there is a race in the design of "scan trigger; scan monitor".
> >
> > Right, I've used pthread to first start the monitoring, before actually
> > triggering the scan. That should be enough.
> >
>
> I think we should look at this, because it requires that all
> applications link to pthreads if we offer such an API. Any thoughts
> about alternative ways, can it not be done over libnl, that libnl
> internally used e.g. select()? The above example is only regarding the
> process context.
>

I think pthreads are not necessary here. If we don't close and open
the nl socket everything should be queued.
Forget that with select(), just send() and recv() (whatever that is
underneath of libnl) should be enough.

- Alex

Re: [PATCH wpan-tools 0/7] iwpan: Support scanning/beaconing

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Tue, 30 Aug 2022 23:17:35 -0400:

> Hi,
> 
> On Mon, Aug 29, 2022 at 8:57 AM Alexander Aring <aahringo@redhat.com> wrote:
> >
> > Hi,
> >
> > On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Hi Alexander,
> > >
> > > aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400:
> > >  
> > > > Hi,
> > > >
> > > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > ...  
> > > > >
> > > > > I've updated the tools so that we have:
> > > > >
> > > > > * "scan trigger" which does not block
> > > > > * "scan monitor" which displays with a pretty output the new
> > > > >   coordinators and stops blocking when the scan is over (either because
> > > > >   it reached the last channel to scan, or it got aborted)
> > > > > * "scan abort" which stops an ongoing scan
> > > > > * "scan" which is the same as "scan trigger; scan monitor", and will  
> > > >
> > > > no, there is a race in the design of "scan trigger; scan monitor".  
> > >
> > > Right, I've used pthread to first start the monitoring, before actually
> > > triggering the scan. That should be enough.
> > >  
> >
> > I think we should look at this, because it requires that all
> > applications link to pthreads if we offer such an API. Any thoughts
> > about alternative ways, can it not be done over libnl, that libnl
> > internally used e.g. select()? The above example is only regarding the
> > process context.
> >  
> 
> I think pthreads are not necessary here. If we don't close and open
> the nl socket everything should be queued.
> Forget that with select(), just send() and recv() (whatever that is
> underneath of libnl) should be enough.

That's way more clever. I've changed that, no more pthread and no more
race, thanks!

Thanks,
Miquèl