[PATCH wpan-next 0/2] ieee802154: Beaconing support

[PATCH wpan-next 0/2] ieee802154: Beaconing support

[Miquel Raynal]

Scanning being now supported, we can eg. play with hwsim to verify
everything works as soon as this series including beaconing support gets
merged.

Thanks,
Miquèl

Miquel Raynal (2):
  ieee802154: Add support for user beaconing requests
  mac802154: Handle basic beaconing

 include/net/cfg802154.h         |  23 +++++
 include/net/ieee802154_netdev.h |  16 ++++
 include/net/nl802154.h          |   3 +
 net/ieee802154/header_ops.c     |  24 +++++
 net/ieee802154/nl802154.c       |  93 ++++++++++++++++++++
 net/ieee802154/nl802154.h       |   1 +
 net/ieee802154/rdev-ops.h       |  28 ++++++
 net/ieee802154/trace.h          |  21 +++++
 net/mac802154/cfg.c             |  31 ++++++-
 net/mac802154/ieee802154_i.h    |  18 ++++
 net/mac802154/iface.c           |   3 +
 net/mac802154/main.c            |   1 +
 net/mac802154/scan.c            | 151 ++++++++++++++++++++++++++++++++
 13 files changed, 411 insertions(+), 2 deletions(-)

-- 
2.34.1

[PATCH wpan-next 1/2] ieee802154: Add support for user beaconing requests

[Miquel Raynal]

Parse user requests for sending beacons, start sending beacons at a
regular pace. If needed, the pace can be updated with a new request. The
process can also be interrupted at any moment.

The page and channel must be changed beforehands if needed. Interval
orders above 14 are reserved to tell a device it must answer BEACON_REQ
coming from another device as part of an active scan procedure and this
is not yet supported.

A netlink "beacon request" structure is created to list the
requirements.

Mac layers may now implement the ->send_beacons() and
->stop_beacons() hooks.

Co-developed-by: David Girault <david.girault@qorvo.com>
Signed-off-by: David Girault <david.girault@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/net/cfg802154.h   | 23 ++++++++++
 include/net/nl802154.h    |  3 ++
 net/ieee802154/nl802154.c | 93 +++++++++++++++++++++++++++++++++++++++
 net/ieee802154/nl802154.h |  1 +
 net/ieee802154/rdev-ops.h | 28 ++++++++++++
 net/ieee802154/trace.h    | 21 +++++++++
 6 files changed, 169 insertions(+)

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index 0b0f81a945b6..0c2778a836db 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -19,6 +19,7 @@
 struct wpan_phy;
 struct wpan_phy_cca;
 struct cfg802154_scan_request;
+struct cfg802154_beacon_request;
 
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 struct ieee802154_llsec_device_key;
@@ -72,6 +73,10 @@ struct cfg802154_ops {
 				struct cfg802154_scan_request *request);
 	int	(*abort_scan)(struct wpan_phy *wpan_phy,
 			      struct wpan_dev *wpan_dev);
+	int	(*send_beacons)(struct wpan_phy *wpan_phy,
+				struct cfg802154_beacon_request *request);
+	int	(*stop_beacons)(struct wpan_phy *wpan_phy,
+				struct wpan_dev *wpan_dev);
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 	void	(*get_llsec_table)(struct wpan_phy *wpan_phy,
 				   struct wpan_dev *wpan_dev,
@@ -314,6 +319,24 @@ struct cfg802154_scan_request {
 	struct wpan_phy *wpan_phy;
 };
 
+/**
+ * struct cfg802154_beacon_request - Beacon request descriptor
+ *
+ * @interval: interval n between sendings, in multiple order of the super frame
+ *            duration: aBaseSuperframeDuration * (2^n) unless the interval
+ *            order is greater or equal to 15, in this case beacons won't be
+ *            passively sent out at a fixed rate but instead inform the device
+ *            that it should answer beacon requests as part of active scan
+ *            procedures
+ * @wpan_dev: the concerned wpan device
+ * @wpan_phy: the wpan phy this was for
+ */
+struct cfg802154_beacon_request {
+	u8 interval;
+	struct wpan_dev *wpan_dev;
+	struct wpan_phy *wpan_phy;
+};
+
 /**
  * struct cfg802154_mac_pkt - MAC packet descriptor (beacon/command)
  * @node: MAC packets to process list member
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index c267fa1c5aac..8cd9d141f5af 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -76,6 +76,8 @@ enum nl802154_commands {
 	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 */
 
@@ -144,6 +146,7 @@ enum nl802154_attrs {
 	NL802154_ATTR_SCAN_MEAN_PRF,
 	NL802154_ATTR_SCAN_DURATION,
 	NL802154_ATTR_SCAN_DONE_REASON,
+	NL802154_ATTR_BEACON_INTERVAL,
 
 	/* add attributes here, update the policy in nl802154.c */
 
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 1d703251f74a..0d9becd678e3 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -227,6 +227,7 @@ static const struct nla_policy nl802154_policy[NL802154_ATTR_MAX+1] = {
 	[NL802154_ATTR_SCAN_MEAN_PRF] = { .type = NLA_U8 },
 	[NL802154_ATTR_SCAN_DURATION] = { .type = NLA_U8 },
 	[NL802154_ATTR_SCAN_DONE_REASON] = { .type = NLA_U8 },
+	[NL802154_ATTR_BEACON_INTERVAL] = { .type = NLA_U8 },
 
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 	[NL802154_ATTR_SEC_ENABLED] = { .type = NLA_U8, },
@@ -1587,6 +1588,82 @@ static int nl802154_abort_scan(struct sk_buff *skb, struct genl_info *info)
 	return rdev_abort_scan(rdev, wpan_dev);
 }
 
+static int
+nl802154_send_beacons(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg802154_registered_device *rdev = info->user_ptr[0];
+	struct net_device *dev = info->user_ptr[1];
+	struct wpan_dev *wpan_dev = dev->ieee802154_ptr;
+	struct wpan_phy *wpan_phy = &rdev->wpan_phy;
+	struct cfg802154_beacon_request *request;
+	int err;
+
+	/* Only coordinators can send beacons */
+	if (wpan_dev->iftype != NL802154_IFTYPE_COORD)
+		return -EOPNOTSUPP;
+
+	if (wpan_dev->pan_id == cpu_to_le16(IEEE802154_PANID_BROADCAST)) {
+		pr_err("Device is not part of any PAN\n");
+		return -EPERM;
+	}
+
+	request = kzalloc(sizeof(*request), GFP_KERNEL);
+	if (!request)
+		return -ENOMEM;
+
+	request->wpan_dev = wpan_dev;
+	request->wpan_phy = wpan_phy;
+
+	if (info->attrs[NL802154_ATTR_BEACON_INTERVAL]) {
+		request->interval = nla_get_u8(info->attrs[NL802154_ATTR_BEACON_INTERVAL]);
+		if (request->interval > IEEE802154_MAX_SCAN_DURATION) {
+			pr_err("Interval is out of range\n");
+			err = -EINVAL;
+			goto free_request;
+		}
+	} else {
+		/* Use maximum duration order by default */
+		request->interval = IEEE802154_MAX_SCAN_DURATION;
+	}
+
+	if (wpan_dev->netdev)
+		dev_hold(wpan_dev->netdev);
+
+	err = rdev_send_beacons(rdev, request);
+	if (err) {
+		pr_err("Failure starting sending beacons (%d)\n", err);
+		goto free_device;
+	}
+
+	return 0;
+
+free_device:
+	if (wpan_dev->netdev)
+		dev_put(wpan_dev->netdev);
+free_request:
+	kfree(request);
+
+	return err;
+}
+
+void nl802154_beaconing_done(struct wpan_dev *wpan_dev)
+{
+	if (wpan_dev->netdev)
+		dev_put(wpan_dev->netdev);
+}
+EXPORT_SYMBOL_GPL(nl802154_beaconing_done);
+
+static int
+nl802154_stop_beacons(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg802154_registered_device *rdev = info->user_ptr[0];
+	struct net_device *dev = info->user_ptr[1];
+	struct wpan_dev *wpan_dev = dev->ieee802154_ptr;
+
+	/* Resources are released in the notification helper above */
+	return rdev_stop_beacons(rdev, wpan_dev);
+}
+
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 static const struct nla_policy nl802154_dev_addr_policy[NL802154_DEV_ADDR_ATTR_MAX + 1] = {
 	[NL802154_DEV_ADDR_ATTR_PAN_ID] = { .type = NLA_U16 },
@@ -2691,6 +2768,22 @@ static const struct genl_ops nl802154_ops[] = {
 				  NL802154_FLAG_CHECK_NETDEV_UP |
 				  NL802154_FLAG_NEED_RTNL,
 	},
+	{
+		.cmd = NL802154_CMD_SEND_BEACONS,
+		.doit = nl802154_send_beacons,
+		.flags = GENL_ADMIN_PERM,
+		.internal_flags = NL802154_FLAG_NEED_NETDEV |
+				  NL802154_FLAG_CHECK_NETDEV_UP |
+				  NL802154_FLAG_NEED_RTNL,
+	},
+	{
+		.cmd = NL802154_CMD_STOP_BEACONS,
+		.doit = nl802154_stop_beacons,
+		.flags = GENL_ADMIN_PERM,
+		.internal_flags = NL802154_FLAG_NEED_NETDEV |
+				  NL802154_FLAG_CHECK_NETDEV_UP |
+				  NL802154_FLAG_NEED_RTNL,
+	},
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 	{
 		.cmd = NL802154_CMD_SET_SEC_PARAMS,
diff --git a/net/ieee802154/nl802154.h b/net/ieee802154/nl802154.h
index cfa7134be747..d69d950f9a6a 100644
--- a/net/ieee802154/nl802154.h
+++ b/net/ieee802154/nl802154.h
@@ -9,5 +9,6 @@ int nl802154_scan_event(struct wpan_phy *wpan_phy, struct wpan_dev *wpan_dev,
 int nl802154_scan_started(struct wpan_phy *wpan_phy, struct wpan_dev *wpan_dev);
 int nl802154_scan_done(struct wpan_phy *wpan_phy, struct wpan_dev *wpan_dev,
 		       enum nl802154_scan_done_reasons reason);
+void nl802154_beaconing_done(struct wpan_dev *wpan_dev);
 
 #endif /* __IEEE802154_NL802154_H */
diff --git a/net/ieee802154/rdev-ops.h b/net/ieee802154/rdev-ops.h
index e171d74c3251..5eaae15c610e 100644
--- a/net/ieee802154/rdev-ops.h
+++ b/net/ieee802154/rdev-ops.h
@@ -237,6 +237,34 @@ static inline int rdev_abort_scan(struct cfg802154_registered_device *rdev,
 	return ret;
 }
 
+static inline int rdev_send_beacons(struct cfg802154_registered_device *rdev,
+				    struct cfg802154_beacon_request *request)
+{
+	int ret;
+
+	if (!rdev->ops->send_beacons)
+		return -EOPNOTSUPP;
+
+	trace_802154_rdev_send_beacons(&rdev->wpan_phy, request);
+	ret = rdev->ops->send_beacons(&rdev->wpan_phy, request);
+	trace_802154_rdev_return_int(&rdev->wpan_phy, ret);
+	return ret;
+}
+
+static inline int rdev_stop_beacons(struct cfg802154_registered_device *rdev,
+				    struct wpan_dev *wpan_dev)
+{
+	int ret;
+
+	if (!rdev->ops->stop_beacons)
+		return -EOPNOTSUPP;
+
+	trace_802154_rdev_stop_beacons(&rdev->wpan_phy, wpan_dev);
+	ret = rdev->ops->stop_beacons(&rdev->wpan_phy, wpan_dev);
+	trace_802154_rdev_return_int(&rdev->wpan_phy, ret);
+	return ret;
+}
+
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 /* TODO this is already a nl802154, so move into ieee802154 */
 static inline void
diff --git a/net/ieee802154/trace.h b/net/ieee802154/trace.h
index e5405f737ded..e5d8439b9e45 100644
--- a/net/ieee802154/trace.h
+++ b/net/ieee802154/trace.h
@@ -315,6 +315,22 @@ TRACE_EVENT(802154_rdev_trigger_scan,
 		  WPAN_PHY_PR_ARG, __entry->page, __entry->channels, __entry->duration)
 );
 
+TRACE_EVENT(802154_rdev_send_beacons,
+	TP_PROTO(struct wpan_phy *wpan_phy,
+		 struct cfg802154_beacon_request *request),
+	TP_ARGS(wpan_phy, request),
+	TP_STRUCT__entry(
+		WPAN_PHY_ENTRY
+		__field(u8, interval)
+	),
+	TP_fast_assign(
+		WPAN_PHY_ASSIGN;
+		__entry->interval = request->interval;
+	),
+	TP_printk(WPAN_PHY_PR_FMT ", sending beacons (interval order: %d)",
+		  WPAN_PHY_PR_ARG, __entry->interval)
+);
+
 DECLARE_EVENT_CLASS(802154_wdev_template,
 	TP_PROTO(struct wpan_phy *wpan_phy, struct wpan_dev *wpan_dev),
 	TP_ARGS(wpan_phy, wpan_dev),
@@ -335,6 +351,11 @@ DEFINE_EVENT(802154_wdev_template, 802154_rdev_abort_scan,
 	TP_ARGS(wpan_phy, wpan_dev)
 );
 
+DEFINE_EVENT(802154_wdev_template, 802154_rdev_stop_beacons,
+	TP_PROTO(struct wpan_phy *wpan_phy, struct wpan_dev *wpan_dev),
+	TP_ARGS(wpan_phy, wpan_dev)
+);
+
 TRACE_EVENT(802154_rdev_return_int,
 	TP_PROTO(struct wpan_phy *wpan_phy, int ret),
 	TP_ARGS(wpan_phy, ret),
-- 
2.34.1

[PATCH wpan-next 2/2] mac802154: Handle basic beaconing

[Miquel Raynal]

Implement the core hooks in order to provide the softMAC layer support
for sending beacons. Coordinators may be requested to send beacons in a
beacon enabled PAN in order for the other devices around to self
discover the available PANs automatically.

Changing the channels is prohibited while a beacon operation is
ongoing.

The implementation uses a workqueue triggered at a certain interval
depending on the symbol duration for the current channel and the
interval order provided.

Sending beacons in response to a BEACON_REQ frame (ie. answering active
scans) is not yet supported.

Co-developed-by: David Girault <david.girault@qorvo.com>
Signed-off-by: David Girault <david.girault@qorvo.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/net/ieee802154_netdev.h |  16 ++++
 net/ieee802154/header_ops.c     |  24 +++++
 net/mac802154/cfg.c             |  31 ++++++-
 net/mac802154/ieee802154_i.h    |  18 ++++
 net/mac802154/iface.c           |   3 +
 net/mac802154/main.c            |   1 +
 net/mac802154/scan.c            | 151 ++++++++++++++++++++++++++++++++
 7 files changed, 242 insertions(+), 2 deletions(-)

diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index 2f2196049a86..da8a3e648c7a 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -129,6 +129,13 @@ enum ieee802154_frame_version {
 	IEEE802154_MULTIPURPOSE_STD = IEEE802154_2003_STD,
 };
 
+enum ieee802154_addressing_mode {
+	IEEE802154_NO_ADDRESSING,
+	IEEE802154_RESERVED,
+	IEEE802154_SHORT_ADDRESSING,
+	IEEE802154_EXTENDED_ADDRESSING,
+};
+
 struct ieee802154_hdr {
 	struct ieee802154_hdr_fc fc;
 	u8 seq;
@@ -137,6 +144,11 @@ struct ieee802154_hdr {
 	struct ieee802154_sechdr sec;
 };
 
+struct ieee802154_beacon_frame {
+	struct ieee802154_hdr mhr;
+	struct ieee802154_beacon_hdr mac_pl;
+};
+
 /* pushes hdr onto the skb. fields of hdr->fc that can be calculated from
  * the contents of hdr will be, and the actual value of those bits in
  * hdr->fc will be ignored. this includes the INTRA_PAN bit and the frame
@@ -162,6 +174,10 @@ int ieee802154_hdr_peek_addrs(const struct sk_buff *skb,
  */
 int ieee802154_hdr_peek(const struct sk_buff *skb, struct ieee802154_hdr *hdr);
 
+/* pushes a beacon frame into an skb */
+int ieee802154_beacon_push(struct sk_buff *skb,
+			   struct ieee802154_beacon_frame *beacon);
+
 int ieee802154_max_payload(const struct ieee802154_hdr *hdr);
 
 static inline int
diff --git a/net/ieee802154/header_ops.c b/net/ieee802154/header_ops.c
index af337cf62764..35d384dfe29d 100644
--- a/net/ieee802154/header_ops.c
+++ b/net/ieee802154/header_ops.c
@@ -120,6 +120,30 @@ ieee802154_hdr_push(struct sk_buff *skb, struct ieee802154_hdr *hdr)
 }
 EXPORT_SYMBOL_GPL(ieee802154_hdr_push);
 
+int ieee802154_beacon_push(struct sk_buff *skb,
+			   struct ieee802154_beacon_frame *beacon)
+{
+	struct ieee802154_beacon_hdr *mac_pl = &beacon->mac_pl;
+	struct ieee802154_hdr *mhr = &beacon->mhr;
+	int ret;
+
+	skb_reserve(skb, sizeof(*mhr));
+	ret = ieee802154_hdr_push(skb, mhr);
+	if (ret < 0)
+		return ret;
+
+	skb_reset_mac_header(skb);
+	skb->mac_len = ret;
+
+	skb_put_data(skb, mac_pl, sizeof(*mac_pl));
+
+	if (mac_pl->pend_short_addr_count || mac_pl->pend_ext_addr_count)
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ieee802154_beacon_push);
+
 static int
 ieee802154_hdr_get_addr(const u8 *buf, int mode, bool omit_pan,
 			struct ieee802154_addr *addr)
diff --git a/net/mac802154/cfg.c b/net/mac802154/cfg.c
index 187cebcaf233..5c3cb019f751 100644
--- a/net/mac802154/cfg.c
+++ b/net/mac802154/cfg.c
@@ -114,8 +114,8 @@ ieee802154_set_channel(struct wpan_phy *wpan_phy, u8 page, u8 channel)
 	    wpan_phy->current_channel == channel)
 		return 0;
 
-	/* Refuse to change channels during a scanning operation */
-	if (mac802154_is_scanning(local))
+	/* Refuse to change channels during scanning or beaconing */
+	if (mac802154_is_scanning(local) || mac802154_is_beaconing(local))
 		return -EBUSY;
 
 	ret = drv_set_channel(local, page, channel);
@@ -290,6 +290,31 @@ static int mac802154_abort_scan(struct wpan_phy *wpan_phy,
 	return mac802154_abort_scan_locked(local, sdata);
 }
 
+static int mac802154_send_beacons(struct wpan_phy *wpan_phy,
+				  struct cfg802154_beacon_request *request)
+{
+	struct ieee802154_sub_if_data *sdata;
+
+	sdata = IEEE802154_WPAN_DEV_TO_SUB_IF(request->wpan_dev);
+
+	ASSERT_RTNL();
+
+	return mac802154_send_beacons_locked(sdata, request);
+}
+
+static int mac802154_stop_beacons(struct wpan_phy *wpan_phy,
+				  struct wpan_dev *wpan_dev)
+{
+	struct ieee802154_local *local = wpan_phy_priv(wpan_phy);
+	struct ieee802154_sub_if_data *sdata;
+
+	sdata = IEEE802154_WPAN_DEV_TO_SUB_IF(wpan_dev);
+
+	ASSERT_RTNL();
+
+	return mac802154_stop_beacons_locked(local, sdata);
+}
+
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 static void
 ieee802154_get_llsec_table(struct wpan_phy *wpan_phy,
@@ -499,6 +524,8 @@ const struct cfg802154_ops mac802154_config_ops = {
 	.set_ackreq_default = ieee802154_set_ackreq_default,
 	.trigger_scan = mac802154_trigger_scan,
 	.abort_scan = mac802154_abort_scan,
+	.send_beacons = mac802154_send_beacons,
+	.stop_beacons = mac802154_stop_beacons,
 #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
 	.get_llsec_table = ieee802154_get_llsec_table,
 	.lock_llsec_table = ieee802154_lock_llsec_table,
diff --git a/net/mac802154/ieee802154_i.h b/net/mac802154/ieee802154_i.h
index 0e4db967bd1d..63bab99ed368 100644
--- a/net/mac802154/ieee802154_i.h
+++ b/net/mac802154/ieee802154_i.h
@@ -23,6 +23,7 @@
 
 enum ieee802154_ongoing {
 	IEEE802154_IS_SCANNING = BIT(0),
+	IEEE802154_IS_BEACONING = BIT(1),
 };
 
 /* mac802154 device private data */
@@ -60,6 +61,12 @@ struct ieee802154_local {
 	struct cfg802154_scan_request __rcu *scan_req;
 	struct delayed_work scan_work;
 
+	/* Beaconing */
+	unsigned int beacon_interval;
+	struct ieee802154_beacon_frame beacon;
+	struct cfg802154_beacon_request __rcu *beacon_req;
+	struct delayed_work beacon_work;
+
 	/* Asynchronous tasks */
 	struct list_head rx_beacon_list;
 	struct work_struct rx_beacon_work;
@@ -257,6 +264,17 @@ static inline bool mac802154_is_scanning(struct ieee802154_local *local)
 	return test_bit(IEEE802154_IS_SCANNING, &local->ongoing);
 }
 
+void mac802154_beacon_worker(struct work_struct *work);
+int mac802154_send_beacons_locked(struct ieee802154_sub_if_data *sdata,
+				  struct cfg802154_beacon_request *request);
+int mac802154_stop_beacons_locked(struct ieee802154_local *local,
+				  struct ieee802154_sub_if_data *sdata);
+
+static inline bool mac802154_is_beaconing(struct ieee802154_local *local)
+{
+	return test_bit(IEEE802154_IS_BEACONING, &local->ongoing);
+}
+
 /* interface handling */
 int ieee802154_iface_init(void);
 void ieee802154_iface_exit(void);
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index a5958d323ea3..9d59caeb74e0 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -305,6 +305,9 @@ static int mac802154_slave_close(struct net_device *dev)
 	if (mac802154_is_scanning(local))
 		mac802154_abort_scan_locked(local, sdata);
 
+	if (mac802154_is_beaconing(local))
+		mac802154_stop_beacons_locked(local, sdata);
+
 	netif_stop_queue(dev);
 	local->open_count--;
 
diff --git a/net/mac802154/main.c b/net/mac802154/main.c
index b1111279e06d..ee23e234b998 100644
--- a/net/mac802154/main.c
+++ b/net/mac802154/main.c
@@ -99,6 +99,7 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops)
 	INIT_WORK(&local->sync_tx_work, ieee802154_xmit_sync_worker);
 	INIT_DELAYED_WORK(&local->scan_work, mac802154_scan_worker);
 	INIT_WORK(&local->rx_beacon_work, mac802154_rx_beacon_worker);
+	INIT_DELAYED_WORK(&local->beacon_work, mac802154_beacon_worker);
 
 	/* init supported flags with 802.15.4 default ranges */
 	phy->supported.max_minbe = 8;
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 56056b9c93c1..5741b995ffc8 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -16,6 +16,11 @@
 #include "driver-ops.h"
 #include "../ieee802154/nl802154.h"
 
+#define IEEE802154_BEACON_MHR_SZ 13
+#define IEEE802154_BEACON_PL_SZ 4
+#define IEEE802154_BEACON_SKB_SZ (IEEE802154_BEACON_MHR_SZ + \
+				  IEEE802154_BEACON_PL_SZ)
+
 /* mac802154_scan_cleanup_locked() must be called upon scan completion or abort.
  * - Completions are asynchronous, not locked by the rtnl and decided by the
  *   scan worker.
@@ -286,3 +291,149 @@ int mac802154_process_beacon(struct ieee802154_local *local,
 
 	return 0;
 }
+
+static int mac802154_transmit_beacon(struct ieee802154_local *local,
+				     struct wpan_dev *wpan_dev)
+{
+	struct cfg802154_beacon_request *beacon_req;
+	struct ieee802154_sub_if_data *sdata;
+	struct sk_buff *skb;
+	int ret;
+
+	/* Update the sequence number */
+	local->beacon.mhr.seq = atomic_inc_return(&wpan_dev->bsn) & 0xFF;
+
+	skb = alloc_skb(IEEE802154_BEACON_SKB_SZ, GFP_KERNEL);
+	if (!skb)
+		return -ENOBUFS;
+
+	rcu_read_lock();
+	beacon_req = rcu_dereference(local->beacon_req);
+	if (unlikely(!beacon_req)) {
+		rcu_read_unlock();
+		kfree_skb(skb);
+		return -EINVAL;
+	}
+
+	sdata = IEEE802154_WPAN_DEV_TO_SUB_IF(beacon_req->wpan_dev);
+	skb->dev = sdata->dev;
+
+	rcu_read_unlock();
+
+	ret = ieee802154_beacon_push(skb, &local->beacon);
+	if (ret) {
+		kfree_skb(skb);
+		return ret;
+	}
+
+	return ieee802154_mlme_tx_one(local, sdata, skb);
+}
+
+void mac802154_beacon_worker(struct work_struct *work)
+{
+	struct ieee802154_local *local =
+		container_of(work, struct ieee802154_local, beacon_work.work);
+	struct cfg802154_beacon_request *beacon_req;
+	struct ieee802154_sub_if_data *sdata;
+	struct wpan_dev *wpan_dev;
+	int ret;
+
+	rcu_read_lock();
+	beacon_req = rcu_dereference(local->beacon_req);
+	if (unlikely(!beacon_req)) {
+		rcu_read_unlock();
+		return;
+	}
+
+	sdata = IEEE802154_WPAN_DEV_TO_SUB_IF(beacon_req->wpan_dev);
+
+	/* Wait an arbitrary amount of time in case we cannot use the device */
+	if (local->suspended || !ieee802154_sdata_running(sdata)) {
+		rcu_read_unlock();
+		queue_delayed_work(local->mac_wq, &local->beacon_work,
+				   msecs_to_jiffies(1000));
+		return;
+	}
+
+	wpan_dev = beacon_req->wpan_dev;
+
+	rcu_read_unlock();
+
+	dev_dbg(&sdata->dev->dev, "Sending beacon\n");
+	ret = mac802154_transmit_beacon(local, wpan_dev);
+	if (ret)
+		dev_err(&sdata->dev->dev,
+			"Beacon could not be transmitted (%d)\n", ret);
+
+	if (local->beacon_interval >= 0)
+		queue_delayed_work(local->mac_wq, &local->beacon_work,
+				   local->beacon_interval);
+}
+
+int mac802154_stop_beacons_locked(struct ieee802154_local *local,
+				  struct ieee802154_sub_if_data *sdata)
+{
+	struct wpan_dev *wpan_dev = &sdata->wpan_dev;
+	struct cfg802154_beacon_request *request;
+
+	ASSERT_RTNL();
+
+	if (!mac802154_is_beaconing(local))
+		return -ESRCH;
+
+	clear_bit(IEEE802154_IS_BEACONING, &local->ongoing);
+	cancel_delayed_work(&local->beacon_work);
+	request = rcu_replace_pointer(local->beacon_req, NULL, 1);
+	if (!request)
+		return 0;
+	kfree_rcu(request);
+
+	nl802154_beaconing_done(wpan_dev);
+
+	return 0;
+}
+
+int mac802154_send_beacons_locked(struct ieee802154_sub_if_data *sdata,
+				  struct cfg802154_beacon_request *request)
+{
+	struct ieee802154_local *local = sdata->local;
+
+	ASSERT_RTNL();
+
+	if (mac802154_is_beaconing(local))
+		mac802154_stop_beacons_locked(local, sdata);
+
+	/* Store beaconing parameters */
+	rcu_assign_pointer(local->beacon_req, request);
+
+	set_bit(IEEE802154_IS_BEACONING, &local->ongoing);
+
+	memset(&local->beacon, 0, sizeof(local->beacon));
+	local->beacon.mhr.fc.type = IEEE802154_FC_TYPE_BEACON;
+	local->beacon.mhr.fc.security_enabled = 0;
+	local->beacon.mhr.fc.frame_pending = 0;
+	local->beacon.mhr.fc.ack_request = 0;
+	local->beacon.mhr.fc.intra_pan = 0;
+	local->beacon.mhr.fc.dest_addr_mode = IEEE802154_NO_ADDRESSING;
+	local->beacon.mhr.fc.version = IEEE802154_2003_STD;
+	local->beacon.mhr.fc.source_addr_mode = IEEE802154_EXTENDED_ADDRESSING;
+	atomic_set(&request->wpan_dev->bsn, -1);
+	local->beacon.mhr.source.mode = IEEE802154_ADDR_LONG;
+	local->beacon.mhr.source.pan_id = cpu_to_le16(request->wpan_dev->pan_id);
+	local->beacon.mhr.source.extended_addr = cpu_to_le64(request->wpan_dev->extended_addr);
+	local->beacon.mac_pl.beacon_order = request->interval;
+	local->beacon.mac_pl.superframe_order = request->interval;
+	local->beacon.mac_pl.final_cap_slot = 0xf;
+	local->beacon.mac_pl.battery_life_ext = 0;
+	/* TODO: Fill this field depending on the coordinator capacity */
+	local->beacon.mac_pl.pan_coordinator = 1;
+	local->beacon.mac_pl.assoc_permit = 1;
+
+	/* Start the beacon work */
+	local->beacon_interval =
+		mac802154_scan_get_channel_time(request->interval,
+						request->wpan_phy->symbol_duration);
+	queue_delayed_work(local->mac_wq, &local->beacon_work, 0);
+
+	return 0;
+}
-- 
2.34.1

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Scanning being now supported, we can eg. play with hwsim to verify
> everything works as soon as this series including beaconing support gets
> merged.
>

I am not sure if a beacon send should be handled by an mlme helper
handling as this is a different use-case and the user does not trigger
an mac command and is waiting for some reply and a more complex
handling could be involved. There is also no need for hotpath xmit
handling is disabled during this time. It is just an async messaging
in some interval and just "try" to send it and don't care if it fails,
or? For mac802154 therefore I think we should use the dev_queue_xmit()
function to queue it up to send it through the hotpath?

I can ack those patches, it will work as well. But I think we should
switch at some point to dev_queue_xmit(). It should be simple to
switch it. Just want to mention there is a difference which will be
there in mac-cmds like association.

btw: what is about security handling... however I would declare this
feature as experimental anyway.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:

> Hi,
> 
> On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Scanning being now supported, we can eg. play with hwsim to verify
> > everything works as soon as this series including beaconing support gets
> > merged.
> >  
> 
> I am not sure if a beacon send should be handled by an mlme helper
> handling as this is a different use-case and the user does not trigger
> an mac command and is waiting for some reply and a more complex
> handling could be involved. There is also no need for hotpath xmit
> handling is disabled during this time. It is just an async messaging
> in some interval and just "try" to send it and don't care if it fails,
> or? For mac802154 therefore I think we should use the dev_queue_xmit()
> function to queue it up to send it through the hotpath?
> 
> I can ack those patches, it will work as well. But I think we should
> switch at some point to dev_queue_xmit(). It should be simple to
> switch it. Just want to mention there is a difference which will be
> there in mac-cmds like association.

I see what you mean. That's indeed true, we might just switch to
a less constrained transmit path.

In practice, what is deliberately "not enough" here is the precision
when sending the beacons, eg. for ranging purposes (UWB) we will need
to send the beacons at a strict pace. But there are two ways for doing
that :
- use a dedicated scheduler (not supported yet)
- move this logic into a firmware, within an embedded controller on the
  PHY

But that is something that we will have to sort out later on. For now,
let's KISS.

> btw: what is about security handling... however I would declare this
> feature as experimental anyway.

I haven't tested the security layer at all yet, would you have a few
commands to start with, which I could try using eg. hwsim?

Thanks,
Miquèl

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Miquel Raynal]

Hi Alexander,

> > btw: what is about security handling... however I would declare this
> > feature as experimental anyway.  
> 
> I haven't tested the security layer at all yet, would you have a few
> commands to start with, which I could try using eg. hwsim?

Using the dev_queue_xmit() doest not bypasses the whole stack anymore,
the beacons got rejected by the llsec layer. I did just hack into it
just to allow unsecure beacons for now:

-       if (hlen < 0 || hdr.fc.type != IEEE802154_FC_TYPE_DATA)
+       if (hlen < 0 ||
+           (hdr.fc.type != IEEE802154_FC_TYPE_DATA &&
+            hdr.fc.type != IEEE802154_FC_TYPE_BEACON))
                return -EINVAL;

I believe that would be enough as a first step, at least for merging
beacons support for now.

However I'll have to look at the spec about security stuff and
beaconing to know how to handle this properly if security was required,
but could you drive me through useful resources were I could quickly
grasp how all that works? Did you make any presentation of it? Perhaps
just a blog post or something alike? Or even just a script showing its
use?

While I was looking at linux-wpan.org, I realized we should both
contribute to it with some examples about security stuff and
beaconing/scanning?

Thanks,
Miquèl

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Mon, Jan 23, 2023 at 7:49 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> > > btw: what is about security handling... however I would declare this
> > > feature as experimental anyway.
> >
> > I haven't tested the security layer at all yet, would you have a few
> > commands to start with, which I could try using eg. hwsim?
>
> Using the dev_queue_xmit() doest not bypasses the whole stack anymore,
> the beacons got rejected by the llsec layer. I did just hack into it
> just to allow unsecure beacons for now:
>

Stupid questions: do the beacon frames need to be encrypted? Because
we bypass llsec always with those mlme functionality.

btw: there is currently an issue with the llsec hooks. You will not
see the transmit side being encrypted via wireshark (so far I
remember) because the capture is before encryption...

> -       if (hlen < 0 || hdr.fc.type != IEEE802154_FC_TYPE_DATA)
> +       if (hlen < 0 ||
> +           (hdr.fc.type != IEEE802154_FC_TYPE_DATA &&
> +            hdr.fc.type != IEEE802154_FC_TYPE_BEACON))
>                 return -EINVAL;
>
> I believe that would be enough as a first step, at least for merging
> beacons support for now.
>

ok.

> However I'll have to look at the spec about security stuff and
> beaconing to know how to handle this properly if security was required,
> but could you drive me through useful resources were I could quickly
> grasp how all that works? Did you make any presentation of it? Perhaps
> just a blog post or something alike? Or even just a script showing its
> use?
>

I am pretty sure I have something... you need to construct an ACL
there and there exist different methods to do a key lookup. Some are
very easy and some are more difficult to set up. I will look later...
or just do a setup again with hwsim with should work (but again don't
trust wireshark/tcpdump).

Also note: currently there exists practical issues on 802.15.4 stack
(but star topology kind of solves it, so far I understood) to
synchronize security parameters e.g. frame counter.

> While I was looking at linux-wpan.org, I realized we should both
> contribute to it with some examples about security stuff and
> beaconing/scanning?
>

yes, that would be nice... I am pretty sure there are some examples on
the mailinglist archive.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
>
> > Hi,
> >
> > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Scanning being now supported, we can eg. play with hwsim to verify
> > > everything works as soon as this series including beaconing support gets
> > > merged.
> > >
> >
> > I am not sure if a beacon send should be handled by an mlme helper
> > handling as this is a different use-case and the user does not trigger
> > an mac command and is waiting for some reply and a more complex
> > handling could be involved. There is also no need for hotpath xmit
> > handling is disabled during this time. It is just an async messaging
> > in some interval and just "try" to send it and don't care if it fails,
> > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > function to queue it up to send it through the hotpath?
> >
> > I can ack those patches, it will work as well. But I think we should
> > switch at some point to dev_queue_xmit(). It should be simple to
> > switch it. Just want to mention there is a difference which will be
> > there in mac-cmds like association.
>
> I see what you mean. That's indeed true, we might just switch to
> a less constrained transmit path.
>

I would define the difference in bypass qdisc or not. Whereas the
qdisc can drop or delay transmitting... For me, the qdisc is currently
in a "works for now" state.

> In practice, what is deliberately "not enough" here is the precision
> when sending the beacons, eg. for ranging purposes (UWB) we will need
> to send the beacons at a strict pace. But there are two ways for doing
> that :
> - use a dedicated scheduler (not supported yet)
> - move this logic into a firmware, within an embedded controller on the
>   PHY
>

then bypassing qdisc would be better.

> But that is something that we will have to sort out later on. For now,
> let's KISS.
>
> > btw: what is about security handling... however I would declare this
> > feature as experimental anyway.
>
> I haven't tested the security layer at all yet, would you have a few
> commands to start with, which I could try using eg. hwsim?

hwsim should work. But again don't trust the transmit side, there are
currently problems. Wireshark has also a feature to give the key and
encrypt on the fly for 802.15.4.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
> >
> > > Hi,
> > >
> > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Scanning being now supported, we can eg. play with hwsim to verify
> > > > everything works as soon as this series including beaconing support gets
> > > > merged.
> > > >
> > >
> > > I am not sure if a beacon send should be handled by an mlme helper
> > > handling as this is a different use-case and the user does not trigger
> > > an mac command and is waiting for some reply and a more complex
> > > handling could be involved. There is also no need for hotpath xmit
> > > handling is disabled during this time. It is just an async messaging
> > > in some interval and just "try" to send it and don't care if it fails,
> > > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > > function to queue it up to send it through the hotpath?
> > >
> > > I can ack those patches, it will work as well. But I think we should
> > > switch at some point to dev_queue_xmit(). It should be simple to
> > > switch it. Just want to mention there is a difference which will be
> > > there in mac-cmds like association.
> >
> > I see what you mean. That's indeed true, we might just switch to
> > a less constrained transmit path.
> >
>
> I would define the difference in bypass qdisc or not. Whereas the
> qdisc can drop or delay transmitting... For me, the qdisc is currently
> in a "works for now" state.

probably also bypass other hooks like tc, etc. :-/ Not sure if we want that.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Mon, Jan 23, 2023 at 8:50 AM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Mon, Jan 23, 2023 at 7:49 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > > > btw: what is about security handling... however I would declare this
> > > > feature as experimental anyway.
> > >
> > > I haven't tested the security layer at all yet, would you have a few
> > > commands to start with, which I could try using eg. hwsim?
> >
> > Using the dev_queue_xmit() doest not bypasses the whole stack anymore,
> > the beacons got rejected by the llsec layer. I did just hack into it
> > just to allow unsecure beacons for now:
> >
>
> Stupid questions: do the beacon frames need to be encrypted? Because
> we bypass llsec always with those mlme functionality.
>
> btw: there is currently an issue with the llsec hooks. You will not
> see the transmit side being encrypted via wireshark (so far I
> remember) because the capture is before encryption...

You can do with hwsim a sniffer device, just create a phy and have
from every node an edge to it, then create a monitor interface on it
and you will see all frames on air correctly encrypted and let
wireshark decrypt it. This is a workaround I had.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Miquel Raynal]

Hi Alexander,

aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500:

> Hi,
> 
> On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote:
> >
> > Hi,
> >
> > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Hi Alexander,
> > >
> > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
> > >  
> > > > Hi,
> > > >
> > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > >
> > > > > Scanning being now supported, we can eg. play with hwsim to verify
> > > > > everything works as soon as this series including beaconing support gets
> > > > > merged.
> > > > >  
> > > >
> > > > I am not sure if a beacon send should be handled by an mlme helper
> > > > handling as this is a different use-case and the user does not trigger
> > > > an mac command and is waiting for some reply and a more complex
> > > > handling could be involved. There is also no need for hotpath xmit
> > > > handling is disabled during this time. It is just an async messaging
> > > > in some interval and just "try" to send it and don't care if it fails,
> > > > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > > > function to queue it up to send it through the hotpath?
> > > >
> > > > I can ack those patches, it will work as well. But I think we should
> > > > switch at some point to dev_queue_xmit(). It should be simple to
> > > > switch it. Just want to mention there is a difference which will be
> > > > there in mac-cmds like association.  
> > >
> > > I see what you mean. That's indeed true, we might just switch to
> > > a less constrained transmit path.
> > >  
> >
> > I would define the difference in bypass qdisc or not. Whereas the
> > qdisc can drop or delay transmitting... For me, the qdisc is currently
> > in a "works for now" state.  
> 
> probably also bypass other hooks like tc, etc. :-/ Not sure if we want that.

Actually, IIUC, we no longer want to go through the entire net stack.
We still want to bypass it but without stopping/flushing the full
queue like with an mlme transmission, so what about using
ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it
is more appropriate.

Thanks,
Miquèl

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500:
>
> > Hi,
> >
> > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Alexander,
> > > >
> > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
> > > >
> > > > > Hi,
> > > > >
> > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > Scanning being now supported, we can eg. play with hwsim to verify
> > > > > > everything works as soon as this series including beaconing support gets
> > > > > > merged.
> > > > > >
> > > > >
> > > > > I am not sure if a beacon send should be handled by an mlme helper
> > > > > handling as this is a different use-case and the user does not trigger
> > > > > an mac command and is waiting for some reply and a more complex
> > > > > handling could be involved. There is also no need for hotpath xmit
> > > > > handling is disabled during this time. It is just an async messaging
> > > > > in some interval and just "try" to send it and don't care if it fails,
> > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > > > > function to queue it up to send it through the hotpath?
> > > > >
> > > > > I can ack those patches, it will work as well. But I think we should
> > > > > switch at some point to dev_queue_xmit(). It should be simple to
> > > > > switch it. Just want to mention there is a difference which will be
> > > > > there in mac-cmds like association.
> > > >
> > > > I see what you mean. That's indeed true, we might just switch to
> > > > a less constrained transmit path.
> > > >
> > >
> > > I would define the difference in bypass qdisc or not. Whereas the
> > > qdisc can drop or delay transmitting... For me, the qdisc is currently
> > > in a "works for now" state.
> >
> > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that.
>
> Actually, IIUC, we no longer want to go through the entire net stack.
> We still want to bypass it but without stopping/flushing the full
> queue like with an mlme transmission, so what about using
> ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it
> is more appropriate.

I do not understand, what do we currently do with mlme ops via the
ieee802154_subif_start_xmit() function, or? So we bypass everything
from dev_queue_xmit() until do_xmit() netdev callback.

I think it is fine, also I think "mostly" only dataframes should go
through dev_queue_xmit(). With a HardMAC transceiver we would have
control about "mostly" other frames than data either. So we should do
everything with mlme-ops do what the spec says (to match up with
HardMAC behaviour?) and don't allow common net hooks/etc. to change
this behaviour?

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Miquel Raynal]

Hi Alexander,

alex.aring@gmail.com wrote on Tue, 24 Jan 2023 21:31:33 -0500:

> Hi,
> 
> On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500:
> >  
> > > Hi,
> > >
> > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote:  
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > >
> > > > > Hi Alexander,
> > > > >
> > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
> > > > >  
> > > > > > Hi,
> > > > > >
> > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > > > >
> > > > > > > Scanning being now supported, we can eg. play with hwsim to verify
> > > > > > > everything works as soon as this series including beaconing support gets
> > > > > > > merged.
> > > > > > >  
> > > > > >
> > > > > > I am not sure if a beacon send should be handled by an mlme helper
> > > > > > handling as this is a different use-case and the user does not trigger
> > > > > > an mac command and is waiting for some reply and a more complex
> > > > > > handling could be involved. There is also no need for hotpath xmit
> > > > > > handling is disabled during this time. It is just an async messaging
> > > > > > in some interval and just "try" to send it and don't care if it fails,
> > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > > > > > function to queue it up to send it through the hotpath?
> > > > > >
> > > > > > I can ack those patches, it will work as well. But I think we should
> > > > > > switch at some point to dev_queue_xmit(). It should be simple to
> > > > > > switch it. Just want to mention there is a difference which will be
> > > > > > there in mac-cmds like association.  
> > > > >
> > > > > I see what you mean. That's indeed true, we might just switch to
> > > > > a less constrained transmit path.
> > > > >  
> > > >
> > > > I would define the difference in bypass qdisc or not. Whereas the
> > > > qdisc can drop or delay transmitting... For me, the qdisc is currently
> > > > in a "works for now" state.  
> > >
> > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that.  
> >
> > Actually, IIUC, we no longer want to go through the entire net stack.
> > We still want to bypass it but without stopping/flushing the full
> > queue like with an mlme transmission, so what about using
> > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it
> > is more appropriate.  
> 
> I do not understand, what do we currently do with mlme ops via the
> ieee802154_subif_start_xmit() function, or? So we bypass everything
> from dev_queue_xmit() until do_xmit() netdev callback.

Yes, that's the plan. We don't want any of the net stack features when
sending beacons.

> I think it is fine, also I think "mostly" only dataframes should go
> through dev_queue_xmit(). With a HardMAC transceiver we would have
> control about "mostly" other frames than data either. So we should do
> everything with mlme-ops do what the spec says (to match up with
> HardMAC behaviour?) and don't allow common net hooks/etc. to change
> this behaviour?

To summarize:
- Data frames -> should go through dev_queue_xmit()
- MLME ops with feedback constraints -> should go through the slow MLME
  path, so ieee802154_mlme_tx*()
- MLME ops without feedback constraints like beacons -> should go
  through the hot path, but not through the whole net stack, so
  ieee802154_subif_start_xmit()

Right now only data frames have security support, I propose we merge
the initial support like that. Right now I am focused on UWB support
(coming next, after the whole active scan/association additions), and
in a second time we would be interested in llsec support for MLME ops.

Does that sounds like a plan? If yes, I'll send a v2 with the right
transmit helper used.

Thanks,
Miquèl

NB: Perhaps a prerequisites of bringing security to the MLME ops would
be to have wpan-tools updated (it looks like the support was never
merged?) as well as a simple example how to use it on linux-wpan.org.

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Wed, Jan 25, 2023 at 5:00 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Alexander,
>
> alex.aring@gmail.com wrote on Tue, 24 Jan 2023 21:31:33 -0500:
>
> > Hi,
> >
> > On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Alexander,
> > >
> > > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > Hi Alexander,
> > > > > >
> > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > >
> > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify
> > > > > > > > everything works as soon as this series including beaconing support gets
> > > > > > > > merged.
> > > > > > > >
> > > > > > >
> > > > > > > I am not sure if a beacon send should be handled by an mlme helper
> > > > > > > handling as this is a different use-case and the user does not trigger
> > > > > > > an mac command and is waiting for some reply and a more complex
> > > > > > > handling could be involved. There is also no need for hotpath xmit
> > > > > > > handling is disabled during this time. It is just an async messaging
> > > > > > > in some interval and just "try" to send it and don't care if it fails,
> > > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > > > > > > function to queue it up to send it through the hotpath?
> > > > > > >
> > > > > > > I can ack those patches, it will work as well. But I think we should
> > > > > > > switch at some point to dev_queue_xmit(). It should be simple to
> > > > > > > switch it. Just want to mention there is a difference which will be
> > > > > > > there in mac-cmds like association.
> > > > > >
> > > > > > I see what you mean. That's indeed true, we might just switch to
> > > > > > a less constrained transmit path.
> > > > > >
> > > > >
> > > > > I would define the difference in bypass qdisc or not. Whereas the
> > > > > qdisc can drop or delay transmitting... For me, the qdisc is currently
> > > > > in a "works for now" state.
> > > >
> > > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that.
> > >
> > > Actually, IIUC, we no longer want to go through the entire net stack.
> > > We still want to bypass it but without stopping/flushing the full
> > > queue like with an mlme transmission, so what about using
> > > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it
> > > is more appropriate.
> >
> > I do not understand, what do we currently do with mlme ops via the
> > ieee802154_subif_start_xmit() function, or? So we bypass everything
> > from dev_queue_xmit() until do_xmit() netdev callback.
>
> Yes, that's the plan. We don't want any of the net stack features when
> sending beacons.
>
> > I think it is fine, also I think "mostly" only dataframes should go
> > through dev_queue_xmit(). With a HardMAC transceiver we would have
> > control about "mostly" other frames than data either. So we should do
> > everything with mlme-ops do what the spec says (to match up with
> > HardMAC behaviour?) and don't allow common net hooks/etc. to change
> > this behaviour?
>
> To summarize:
> - Data frames -> should go through dev_queue_xmit()

there are exceptions... e.g. AF_PACKET raw sockets can build whatever
it wants (but it will probably not being supported by HardMAC
transceivers) and send it out. There is no real control about it. So
mostly I would agree here.

> - MLME ops with feedback constraints -> should go through the slow MLME
>   path, so ieee802154_mlme_tx*()

yea.

> - MLME ops without feedback constraints like beacons -> should go
>   through the hot path, but not through the whole net stack, so
>   ieee802154_subif_start_xmit()
>

it will bypass the qdisc handling (+ some other things which are
around there). The current difference is what I see llsec handling and
other things which might be around there? It depends if other
"MLME-ops" need to be e.g. encrypted or not.

> Right now only data frames have security support, I propose we merge
> the initial support like that. Right now I am focused on UWB support
> (coming next, after the whole active scan/association additions), and
> in a second time we would be interested in llsec support for MLME ops.
>

that's fine.

> Does that sounds like a plan? If yes, I'll send a v2 with the right
> transmit helper used.
>

yes.

> Thanks,
> Miquèl
>
> NB: Perhaps a prerequisites of bringing security to the MLME ops would
> be to have wpan-tools updated (it looks like the support was never
> merged?) as well as a simple example how to use it on linux-wpan.org.
>

this is correct. It is still in a branch, I am fine to merge it in
this state although it's not really practical to use right now.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Thu, Jan 26, 2023 at 8:29 PM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Wed, Jan 25, 2023 at 5:00 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Alexander,
> >
> > alex.aring@gmail.com wrote on Tue, 24 Jan 2023 21:31:33 -0500:
> >
> > > Hi,
> > >
> > > On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Alexander,
> > > >
> > > > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500:
> > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > >
> > > > > > > Hi Alexander,
> > > > > > >
> > > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > > > > >
> > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify
> > > > > > > > > everything works as soon as this series including beaconing support gets
> > > > > > > > > merged.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I am not sure if a beacon send should be handled by an mlme helper
> > > > > > > > handling as this is a different use-case and the user does not trigger
> > > > > > > > an mac command and is waiting for some reply and a more complex
> > > > > > > > handling could be involved. There is also no need for hotpath xmit
> > > > > > > > handling is disabled during this time. It is just an async messaging
> > > > > > > > in some interval and just "try" to send it and don't care if it fails,
> > > > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit()
> > > > > > > > function to queue it up to send it through the hotpath?
> > > > > > > >
> > > > > > > > I can ack those patches, it will work as well. But I think we should
> > > > > > > > switch at some point to dev_queue_xmit(). It should be simple to
> > > > > > > > switch it. Just want to mention there is a difference which will be
> > > > > > > > there in mac-cmds like association.
> > > > > > >
> > > > > > > I see what you mean. That's indeed true, we might just switch to
> > > > > > > a less constrained transmit path.
> > > > > > >
> > > > > >
> > > > > > I would define the difference in bypass qdisc or not. Whereas the
> > > > > > qdisc can drop or delay transmitting... For me, the qdisc is currently
> > > > > > in a "works for now" state.
> > > > >
> > > > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that.
> > > >
> > > > Actually, IIUC, we no longer want to go through the entire net stack.
> > > > We still want to bypass it but without stopping/flushing the full
> > > > queue like with an mlme transmission, so what about using
> > > > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it
> > > > is more appropriate.
> > >
> > > I do not understand, what do we currently do with mlme ops via the
> > > ieee802154_subif_start_xmit() function, or? So we bypass everything
> > > from dev_queue_xmit() until do_xmit() netdev callback.
> >
> > Yes, that's the plan. We don't want any of the net stack features when
> > sending beacons.
> >
> > > I think it is fine, also I think "mostly" only dataframes should go
> > > through dev_queue_xmit(). With a HardMAC transceiver we would have
> > > control about "mostly" other frames than data either. So we should do
> > > everything with mlme-ops do what the spec says (to match up with
> > > HardMAC behaviour?) and don't allow common net hooks/etc. to change
> > > this behaviour?
> >
> > To summarize:
> > - Data frames -> should go through dev_queue_xmit()
>
> there are exceptions... e.g. AF_PACKET raw sockets can build whatever
> it wants (but it will probably not being supported by HardMAC
> transceivers) and send it out. There is no real control about it. So
> mostly I would agree here.
>

with "no real control" I mean the user needs to know what it's doing
there and maybe the user just wants to play around e.g. monitor
interface sending, whereas a monitor does not have an address being
set up.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]


Alexander Aring <aahringo@redhat.com> wrote:
    >> - MLME ops without feedback constraints like beacons -> should go
    >> through the hot path, but not through the whole net stack, so
    >> ieee802154_subif_start_xmit()
    >>

    > it will bypass the qdisc handling (+ some other things which are around
    > there). The current difference is what I see llsec handling and other
    > things which might be around there? It depends if other "MLME-ops" need
    > to be e.g. encrypted or not.

I haven't followed the whole thread.
So I am neither agreeing nor disagreeing, just clarifying.
Useful beacons are "signed" (have integrity applied), but not encrypted.

It's important for userspace to be able to receive them, even if we don't
have a key that can verify them.  AFAIK, we have no specific interface to
receive beacons.

    >> NB: Perhaps a prerequisites of bringing security to the MLME ops would
    >> be to have wpan-tools updated (it looks like the support was never
    >> merged?) as well as a simple example how to use it on linux-wpan.org.
    >>

    > this is correct. It is still in a branch, I am fine to merge it in this
    > state although it's not really practical to use right now.

:-)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Alexander Aring]

Hi,

On Fri, Jan 27, 2023 at 2:52 PM Michael Richardson <mcr@sandelman.ca> wrote:
>
>
> Alexander Aring <aahringo@redhat.com> wrote:
>     >> - MLME ops without feedback constraints like beacons -> should go
>     >> through the hot path, but not through the whole net stack, so
>     >> ieee802154_subif_start_xmit()
>     >>
>
>     > it will bypass the qdisc handling (+ some other things which are around
>     > there). The current difference is what I see llsec handling and other
>     > things which might be around there? It depends if other "MLME-ops" need
>     > to be e.g. encrypted or not.
>
> I haven't followed the whole thread.
> So I am neither agreeing nor disagreeing, just clarifying.
> Useful beacons are "signed" (have integrity applied), but not encrypted.
>

I see. But that means they need to be going through llsec, just the
payload isn't encrypted and the MIC is appended to provide integrity.

> It's important for userspace to be able to receive them, even if we don't
> have a key that can verify them.  AFAIK, we have no specific interface to
> receive beacons.
>

This can be done over multiple ways. Either over a socket
communication or if they appear rarely we can put them into a netlink
event. In my opinion we already put that in a higher level API in
passive scan to interpret the receiving of a beacon on kernel level
and trigger netlink events.

I am not sure how HardMAC transceivers handle them on the transceiver
side only or if they ever provide them to the next layer or not?
For SoftMAC you can actually create a AF_PACKET raw socket, and you
should see everything which bypass hardware address filters and kernel
filters. Then an application can listen to them.

- Alex

Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

[Miquel Raynal]

Hello,

aahringo@redhat.com wrote on Fri, 27 Jan 2023 20:57:08 -0500:

> Hi,
> 
> On Fri, Jan 27, 2023 at 2:52 PM Michael Richardson <mcr@sandelman.ca> wrote:
> >
> >
> > Alexander Aring <aahringo@redhat.com> wrote:  
> >     >> - MLME ops without feedback constraints like beacons -> should go
> >     >> through the hot path, but not through the whole net stack, so
> >     >> ieee802154_subif_start_xmit()
> >     >>  
> >  
> >     > it will bypass the qdisc handling (+ some other things which are around
> >     > there). The current difference is what I see llsec handling and other
> >     > things which might be around there?

Not exactly, because llsec handling is not done in the net/ stack, but
right inside the ieee802154 transmit callbacks, so I'd say it will be
quite easy to tweak when we have a clear view of what we want in terms
of encryption/integrity checking/signatures.

> >     > It depends if other "MLME-ops" need
> >     > to be e.g. encrypted or not.  
> >
> > I haven't followed the whole thread.
> > So I am neither agreeing nor disagreeing, just clarifying.
> > Useful beacons are "signed" (have integrity applied), but not encrypted.
> >  
> 
> I see. But that means they need to be going through llsec, just the
> payload isn't encrypted and the MIC is appended to provide integrity.
> 
> > It's important for userspace to be able to receive them, even if we don't
> > have a key that can verify them.  AFAIK, we have no specific interface to
> > receive beacons.
> >  
> 
> This can be done over multiple ways. Either over a socket
> communication or if they appear rarely we can put them into a netlink
> event. In my opinion we already put that in a higher level API in
> passive scan to interpret the receiving of a beacon on kernel level
> and trigger netlink events.

Indeed.

> I am not sure how HardMAC transceivers handle them on the transceiver
> side only or if they ever provide them to the next layer or not?
> For SoftMAC you can actually create a AF_PACKET raw socket, and you
> should see everything which bypass hardware address filters and kernel
> filters. Then an application can listen to them.

Thanks,
Miquèl