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
| ||
|
Message-ID: <CAK-6q+i=biD0pgWsY002PpY_bp3bM56=PdMgqdo5x4bH+JsznA@mail.gmail.com> Date: Mon, 13 Nov 2023 07:52:25 -0500 From: Alexander Aring <aahringo@...hat.com> To: Miquel Raynal <miquel.raynal@...tlin.com> Cc: Alexander Aring <alex.aring@...il.com>, Stefan Schmidt <stefan@...enfreihafen.org>, 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 v5 00/11] ieee802154: Associations between devices Hi, On Wed, Sep 27, 2023 at 2:12 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote: > > Hello, > > Now that we can discover our peer coordinators or make ourselves > dynamically discoverable, we may use the information about surrounding > devices to create PANs dynamically. This involves of course: > * Requesting an association to a coordinator, waiting for the response > * Sending a disassociation notification to a coordinator > * Receiving an association request when we are coordinator, answering > the request (for now all devices are accepted up to a limit, to be > refined) > * Sending a disassociation notification to a child > * Users may request the list of associated devices (the parent and the > children). > > Here are a few example of userspace calls that can be made: > iwpan dev <dev> associate pan_id 2 coord $COORD > iwpan dev <dev> list_associations > iwpan dev <dev> disassociate ext_addr $COORD > > I used a small using hwsim to scan for a coordinator, associate with > it, look at the associations on both sides, disassociate from it and > check the associations again: > ./assoc-demo > *** Scan *** > PAN 0x0002 (on wpan1) > coordinator 0x060f3b35169a498f > page 0 > channel 13 > preamble code 0 > mean prf 0 > superframe spec. 0xcf11 > LQI ff > *** End of scan *** > Associating wpan1 with coord0 0x060f3b35169a498f... > Dumping coord0 assoc: > child : 0x0b6f / 0xba7633ae47ccfb21 > Dumping wpan1 assoc: > parent: 0xffff / 0x060f3b35169a498f > Disassociating from wpan1 > Dumping coord0 assoc: > Dumping wpan1 assoc: > > I could also successfully interact with a smaller device running Zephir, > using its command line interface to associate and then disassociate from > the Linux coordinator. > > Thanks! > Miquèl > > Changes in v5: > * Fixed (again) the helper supposed to check whether a device requesting > association/disassociation is already (or not) in our PAN. We don't > nee to check short addresses there. > * Changed the name of the helper a second time to make it more relevant > and understandable: > cfg802154_device_in_pan() -> cfg802154_pan_device_is_matching() > * Fixed a kernel test robot report where we would use an int instead of > a __le16. Solved that by using cpu_to_le16 like in the other places > where we use definitions as arguments. > > Changes in v4: > * Ensured any disassociation would only be processed if the destination > pan ID matches ours. > * Association requests should be made using extended addressing, it's > the specification, so ensure this is true. Doing so helps reducing the > checks down the road. > * Updated a copyright from 2021 to 2023. > * Improved the comment for cfg802154_device_in_pan() and only accept > extended addressing when using this internal function because there is > no point in checking short addresses here. > * Move nl802154_prepare_wpan_dev_dump() and > nl802154_finish_wpan_dev_dump() outside of a > CONFIG_IEEE802154_NL802154_EXPERIMENTAL #ifdef bloc as now used in > regular code (not only experimental). > * Added a missing return value in the kernel doc of > cfg802154_device_is_associated(). > > Changes in v3: > * Clarify a helper which compares if two devices seem to be identical by > adding two comments. This is a static function that is only used by > the PAN management core to operate or not an > association/disassociation request. In this helper, a new check is > introduced to be sure we compare fields which have been populated. > * Dropped the "association_generation" counter and all its uses along > the code. I tried to mimic some other counter but I agree it is not > super useful and could be dropped anyway. > * Dropped a faulty sequence number hardcoded to 10. This had no impact > because a few lines later the same entry was set to a valid value. > > Changes in v2: > * Drop the misleading IEEE802154_ADDR_LONG_BROADCAST definition and its > only use which was useless anyway. > * Clarified how devices are defined when the user requests to associate > with a coordinator: for now only the extended address of the > coordinator is relevant so this is the only address we care about. > * Drop a useless NULL check before a kfree() call. > * Add a check when allocating a child short address: it must be > different than ours. > * Rebased on top of v6.5. Acked-by: Alexander Aring <aahringo@...hat.com> Thanks for working on this! - Alex
Powered by blists - more mailing lists