lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Sep 2023 09:08:08 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Stefan Schmidt <stefan@...enfreihafen.org>
Cc: Alexander Aring <alex.aring@...il.com>, linux-wpan@...r.kernel.org,
 "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
 netdev@...r.kernel.org, David Girault <david.girault@...vo.com>, Romuald
 Despres <romuald.despres@...vo.com>, Frederic Blain
 <frederic.blain@...vo.com>, Nicolas Schodet <nico@...fr.eu.org>, Guilhem
 Imberton <guilhem.imberton@...vo.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next v2 11/11] ieee802154: Give the user the
 association list

Hi Stefan,

stefan@...enfreihafen.org wrote on Sat, 16 Sep 2023 17:36:41 +0200:

> Hello Miquel.
> 
> On 01.09.23 19:05, Miquel Raynal wrote:
> > Upon request, we must be able to provide to the user the list of
> > associations currently in place. Let's add a new netlink command and
> > attribute for this purpose.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> > ---
> >   include/net/nl802154.h    |  18 ++++++-
> >   net/ieee802154/nl802154.c | 107 ++++++++++++++++++++++++++++++++++++++
> >   2 files changed, 123 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/net/nl802154.h b/include/net/nl802154.h
> > index 8b26faae49e8..4c752f799957 100644
> > --- a/include/net/nl802154.h
> > +++ b/include/net/nl802154.h
> > @@ -81,6 +81,7 @@ enum nl802154_commands {
> >   	NL802154_CMD_ASSOCIATE,
> >   	NL802154_CMD_DISASSOCIATE,
> >   	NL802154_CMD_SET_MAX_ASSOCIATIONS,
> > +	NL802154_CMD_LIST_ASSOCIATIONS,  
> >   >   	/* add new commands above here */
> >   > @@ -151,6 +152,7 @@ enum nl802154_attrs {  
> >   	NL802154_ATTR_SCAN_DONE_REASON,
> >   	NL802154_ATTR_BEACON_INTERVAL,
> >   	NL802154_ATTR_MAX_ASSOCIATIONS,
> > +	NL802154_ATTR_PEER,  
> >   >   	/* add attributes here, update the policy in nl802154.c */
> >   > @@ -389,8 +391,6 @@ enum nl802154_supported_bool_states {  
> >   	NL802154_SUPPORTED_BOOL_MAX = __NL802154_SUPPORTED_BOOL_AFTER_LAST - 1
> >   };  
> >   > -#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL  
> > -
> >   enum nl802154_dev_addr_modes {
> >   	NL802154_DEV_ADDR_NONE,
> >   	__NL802154_DEV_ADDR_INVALID,
> > @@ -410,12 +410,26 @@ enum nl802154_dev_addr_attrs {
> >   	NL802154_DEV_ADDR_ATTR_SHORT,
> >   	NL802154_DEV_ADDR_ATTR_EXTENDED,
> >   	NL802154_DEV_ADDR_ATTR_PAD,
> > +	NL802154_DEV_ADDR_ATTR_PEER_TYPE,  
> >   >   	/* keep last */  
> >   	__NL802154_DEV_ADDR_ATTR_AFTER_LAST,
> >   	NL802154_DEV_ADDR_ATTR_MAX = __NL802154_DEV_ADDR_ATTR_AFTER_LAST - 1
> >   };  
> >   > +enum nl802154_peer_type {  
> > +	NL802154_PEER_TYPE_UNSPEC,
> > +
> > +	NL802154_PEER_TYPE_PARENT,
> > +	NL802154_PEER_TYPE_CHILD,
> > +
> > +	/* keep last */
> > +	__NL802154_PEER_TYPE_AFTER_LAST,
> > +	NL802154_PEER_TYPE_MAX = __NL802154_PEER_TYPE_AFTER_LAST - 1
> > +};
> > +
> > +#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
> > +
> >   enum nl802154_key_id_modes {
> >   	NL802154_KEY_ID_MODE_IMPLICIT,
> >   	NL802154_KEY_ID_MODE_INDEX,
> > diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
> > index e16e57fc34d0..e26d7cec02ce 100644
> > --- a/net/ieee802154/nl802154.c
> > +++ b/net/ieee802154/nl802154.c
> > @@ -235,6 +235,7 @@ static const struct nla_policy nl802154_policy[NL802154_ATTR_MAX+1] = {
> >   	[NL802154_ATTR_BEACON_INTERVAL] =
> >   		NLA_POLICY_MAX(NLA_U8, IEEE802154_ACTIVE_SCAN_DURATION),
> >   	[NL802154_ATTR_MAX_ASSOCIATIONS] = { .type = NLA_U32 },
> > +	[NL802154_ATTR_PEER] = { .type = NLA_NESTED },  
> >   >   #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL  
> >   	[NL802154_ATTR_SEC_ENABLED] = { .type = NLA_U8, },
> > @@ -1717,6 +1718,107 @@ static int nl802154_set_max_associations(struct sk_buff *skb, struct genl_info *
> >   	return 0;
> >   }  
> >   > +static int nl802154_send_peer_info(struct sk_buff *msg,  
> > +				   struct netlink_callback *cb,
> > +				   u32 seq, int flags,
> > +				   struct cfg802154_registered_device *rdev,
> > +				   struct wpan_dev *wpan_dev,
> > +				   struct ieee802154_pan_device *peer,
> > +				   enum nl802154_peer_type type)
> > +{
> > +	struct nlattr *nla;
> > +	void *hdr;
> > +
> > +	ASSERT_RTNL();
> > +
> > +	hdr = nl802154hdr_put(msg, NETLINK_CB(cb->skb).portid, seq, flags,
> > +			      NL802154_CMD_LIST_ASSOCIATIONS);
> > +	if (!hdr)
> > +		return -ENOBUFS;
> > +
> > +	genl_dump_check_consistent(cb, hdr);
> > +
> > +	if (nla_put_u32(msg, NL802154_ATTR_GENERATION,
> > +			wpan_dev->association_generation))  
> 
> 
> This one still confuses me. I only ever see it increasing in the code. Did I miss something?

I think I took inspiration from nl802154_send_wpan_phy() and
and nl802154_send_iface() which both use an increasing counter to tell
userspace the "version" of the data that is being sent. If the
"version" numbers are identical, the user (I guess) can assume nothing
changed and save itself from parsing the whole payload or something
like that.

TBH I just tried here to mimic the existing behavior inside
nl802154_send_peer_info(), but I will drop that counter with no regrets.

Thanks,
Miquèl

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ