mbox series

[wpan-next,v3,0/6] IEEE 802.15.4 passive scan support

Message ID 20230103165644.432209-1-miquel.raynal@bootlin.com (mailing list archive)
Headers show
Series IEEE 802.15.4 passive scan support | expand

Message

Miquel Raynal Jan. 3, 2023, 4:56 p.m. UTC
Hello,

We now have the infrastructure to report beacons/PANs, we also have the
capability to transmit MLME commands synchronously. It is time to use
these to implement a proper scan implementation.

There are a few side-changes which are necessary for the soft MAC scan
implementation to compile/work, but nothing big. The two main changes
are:
* The introduction of a user API for managing scans.
* The soft MAC implementation of a scan.

In all the past, current and future submissions, David and Romuald from
Qorvo are credited in various ways (main author, co-author,
suggested-by) depending of the amount of rework that was involved on
each patch, reflecting as much as possible the open-source guidelines we
follow in the kernel. All this effort is made possible thanks to Qorvo
Inc which is pushing towards a featureful upstream WPAN support.

Example of output:

	# iwpan monitor
	coord1 (phy #1): scan started
	coord1 (phy #1): beacon received: PAN 0xabcd, addr 0xb2bcc36ac5570abe
	coord1 (phy #1): scan finished
	coord1 (phy #1): scan started
	coord1 (phy #1): scan aborted

Cheers,
Miquèl

Changes in v3:
* Fixed most checkpatch.pl issues. A few remain to keep the visual
  consistent with the existing code (in the trace.h files).
* Added Alexander's Acked-by on each patch.

Changes in v2:
* Different way to forward the reason why a scan was terminated, instead
  of providing two different "commands" we provide the same "scan done"
  command and aside an attribute, saying whether the scan was aborted by
  the user or terminated by itself at the end of the required list of
  (complex) channels to scan.

Miquel Raynal (6):
  ieee802154: Add support for user scanning requests
  ieee802154: Define a beacon frame header
  ieee802154: Introduce a helper to validate a channel
  mac802154: Prepare forcing specific symbol duration
  mac802154: Add MLME Tx locked helpers
  mac802154: Handle passive scanning

 include/linux/ieee802154.h      |   7 +
 include/net/cfg802154.h         |  55 +++++-
 include/net/ieee802154_netdev.h |  36 ++++
 include/net/nl802154.h          |  58 +++++++
 net/ieee802154/nl802154.c       | 223 ++++++++++++++++++++++++-
 net/ieee802154/nl802154.h       |   3 +
 net/ieee802154/rdev-ops.h       |  28 ++++
 net/ieee802154/trace.h          |  40 +++++
 net/mac802154/Makefile          |   2 +-
 net/mac802154/cfg.c             |  33 +++-
 net/mac802154/ieee802154_i.h    |  43 ++++-
 net/mac802154/iface.c           |   3 +
 net/mac802154/main.c            |  36 ++--
 net/mac802154/rx.c              |  36 +++-
 net/mac802154/scan.c            | 288 ++++++++++++++++++++++++++++++++
 net/mac802154/tx.c              |  42 +++--
 16 files changed, 901 insertions(+), 32 deletions(-)
 create mode 100644 net/mac802154/scan.c

Comments

Stefan Schmidt Jan. 3, 2023, 7:43 p.m. UTC | #1
Hello Miquel.

On 03.01.23 17:56, Miquel Raynal wrote:
> Hello,
> 
> We now have the infrastructure to report beacons/PANs, we also have the
> capability to transmit MLME commands synchronously. It is time to use
> these to implement a proper scan implementation.
> 
> There are a few side-changes which are necessary for the soft MAC scan
> implementation to compile/work, but nothing big. The two main changes
> are:
> * The introduction of a user API for managing scans.
> * The soft MAC implementation of a scan.
> 
> In all the past, current and future submissions, David and Romuald from
> Qorvo are credited in various ways (main author, co-author,
> suggested-by) depending of the amount of rework that was involved on
> each patch, reflecting as much as possible the open-source guidelines we
> follow in the kernel. All this effort is made possible thanks to Qorvo
> Inc which is pushing towards a featureful upstream WPAN support.
> 
> Example of output:
> 
> 	# iwpan monitor
> 	coord1 (phy #1): scan started
> 	coord1 (phy #1): beacon received: PAN 0xabcd, addr 0xb2bcc36ac5570abe
> 	coord1 (phy #1): scan finished
> 	coord1 (phy #1): scan started
> 	coord1 (phy #1): scan aborted

These patches have been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!

Before I would add them to a pull request to net-next I would like to 
have an updated patchset for iwpan to reflect these scan changes. We 
would need something to verify the kernel changes and try to coordinate 
a new iwpan release with this functionality with the major kernel 
release bringing the feature.

Thanks again for your work.

regards
Stefan Schmidt
Miquel Raynal Jan. 4, 2023, 12:20 p.m. UTC | #2
Hi Stefan,

stefan@datenfreihafen.org wrote on Tue, 3 Jan 2023 20:43:02 +0100:

> Hello Miquel.
> 
> On 03.01.23 17:56, Miquel Raynal wrote:
> > Hello,
> > 
> > We now have the infrastructure to report beacons/PANs, we also have the
> > capability to transmit MLME commands synchronously. It is time to use
> > these to implement a proper scan implementation.
> > 
> > There are a few side-changes which are necessary for the soft MAC scan
> > implementation to compile/work, but nothing big. The two main changes
> > are:
> > * The introduction of a user API for managing scans.
> > * The soft MAC implementation of a scan.
> > 
> > In all the past, current and future submissions, David and Romuald from
> > Qorvo are credited in various ways (main author, co-author,
> > suggested-by) depending of the amount of rework that was involved on
> > each patch, reflecting as much as possible the open-source guidelines we
> > follow in the kernel. All this effort is made possible thanks to Qorvo
> > Inc which is pushing towards a featureful upstream WPAN support.
> > 
> > Example of output:
> > 
> > 	# iwpan monitor
> > 	coord1 (phy #1): scan started
> > 	coord1 (phy #1): beacon received: PAN 0xabcd, addr 0xb2bcc36ac5570abe
> > 	coord1 (phy #1): scan finished
> > 	coord1 (phy #1): scan started
> > 	coord1 (phy #1): scan aborted  
> 
> These patches have been applied to the wpan-next tree and will be
> part of the next pull request to net-next. Thanks!
> 
> Before I would add them to a pull request to net-next I would like to have an updated patchset for iwpan to reflect these scan changes. We would need something to verify the kernel changes and try to coordinate a new iwpan release with this functionality with the major kernel release bringing the feature.

So far I did not made a single change for the scan, but a common
changeset for scan+beaconing (which I am about to send), should I split
it or should we assume we could introduce scanning and beaconing in the
same kernel release?

Thanks,
Miquèl
Stefan Schmidt Jan. 4, 2023, 12:28 p.m. UTC | #3
Hello Miquel.

On 04.01.23 13:20, Miquel Raynal wrote:
> Hi Stefan,
> 
> stefan@datenfreihafen.org wrote on Tue, 3 Jan 2023 20:43:02 +0100:
> 
>> Hello Miquel.
>>
>> On 03.01.23 17:56, Miquel Raynal wrote:
>>> Hello,
>>>
>>> We now have the infrastructure to report beacons/PANs, we also have the
>>> capability to transmit MLME commands synchronously. It is time to use
>>> these to implement a proper scan implementation.
>>>
>>> There are a few side-changes which are necessary for the soft MAC scan
>>> implementation to compile/work, but nothing big. The two main changes
>>> are:
>>> * The introduction of a user API for managing scans.
>>> * The soft MAC implementation of a scan.
>>>
>>> In all the past, current and future submissions, David and Romuald from
>>> Qorvo are credited in various ways (main author, co-author,
>>> suggested-by) depending of the amount of rework that was involved on
>>> each patch, reflecting as much as possible the open-source guidelines we
>>> follow in the kernel. All this effort is made possible thanks to Qorvo
>>> Inc which is pushing towards a featureful upstream WPAN support.
>>>
>>> Example of output:
>>>
>>> 	# iwpan monitor
>>> 	coord1 (phy #1): scan started
>>> 	coord1 (phy #1): beacon received: PAN 0xabcd, addr 0xb2bcc36ac5570abe
>>> 	coord1 (phy #1): scan finished
>>> 	coord1 (phy #1): scan started
>>> 	coord1 (phy #1): scan aborted
>>
>> These patches have been applied to the wpan-next tree and will be
>> part of the next pull request to net-next. Thanks!
>>
>> Before I would add them to a pull request to net-next I would like to have an updated patchset for iwpan to reflect these scan changes. We would need something to verify the kernel changes and try to coordinate a new iwpan release with this functionality with the major kernel release bringing the feature.
> 
> So far I did not made a single change for the scan, but a common
> changeset for scan+beaconing (which I am about to send), should I split
> it or should we assume we could introduce scanning and beaconing in the
> same kernel release?

 From my side I do not mind to introduce scanning and beaconing in the 
same release. I just want to make you aware that scanning would slip if 
beaconing slips and we have no support in iwpan to test and release 
together.

If you have the beaconing patchset ready, let's start with it and if it 
turns out it will not be ready for the next release (let's hope it will) 
you can think again if you want to have the scan part split of to 
release that earlier.

regards
Stefan Schmidt
Miquel Raynal Jan. 6, 2023, 11:22 a.m. UTC | #4
Hi Stefan,

stefan@datenfreihafen.org wrote on Wed, 4 Jan 2023 13:28:44 +0100:

> Hello Miquel.
> 
> On 04.01.23 13:20, Miquel Raynal wrote:
> > Hi Stefan,
> > 
> > stefan@datenfreihafen.org wrote on Tue, 3 Jan 2023 20:43:02 +0100:
> >   
> >> Hello Miquel.
> >>
> >> On 03.01.23 17:56, Miquel Raynal wrote:  
> >>> Hello,
> >>>
> >>> We now have the infrastructure to report beacons/PANs, we also have the
> >>> capability to transmit MLME commands synchronously. It is time to use
> >>> these to implement a proper scan implementation.
> >>>
> >>> There are a few side-changes which are necessary for the soft MAC scan
> >>> implementation to compile/work, but nothing big. The two main changes
> >>> are:
> >>> * The introduction of a user API for managing scans.
> >>> * The soft MAC implementation of a scan.
> >>>
> >>> In all the past, current and future submissions, David and Romuald from
> >>> Qorvo are credited in various ways (main author, co-author,
> >>> suggested-by) depending of the amount of rework that was involved on
> >>> each patch, reflecting as much as possible the open-source guidelines we
> >>> follow in the kernel. All this effort is made possible thanks to Qorvo
> >>> Inc which is pushing towards a featureful upstream WPAN support.
> >>>
> >>> Example of output:
> >>>
> >>> 	# iwpan monitor
> >>> 	coord1 (phy #1): scan started
> >>> 	coord1 (phy #1): beacon received: PAN 0xabcd, addr 0xb2bcc36ac5570abe
> >>> 	coord1 (phy #1): scan finished
> >>> 	coord1 (phy #1): scan started
> >>> 	coord1 (phy #1): scan aborted  
> >>
> >> These patches have been applied to the wpan-next tree and will be
> >> part of the next pull request to net-next. Thanks!
> >>
> >> Before I would add them to a pull request to net-next I would like to have an updated patchset for iwpan to reflect these scan changes. We would need something to verify the kernel changes and try to coordinate a new iwpan release with this functionality with the major kernel release bringing the feature.  
> > 
> > So far I did not made a single change for the scan, but a common
> > changeset for scan+beaconing (which I am about to send), should I split
> > it or should we assume we could introduce scanning and beaconing in the
> > same kernel release?  
> 
>  From my side I do not mind to introduce scanning and beaconing in the same release. I just want to make you aware that scanning would slip if beaconing slips and we have no support in iwpan to test and release together.
> 
> If you have the beaconing patchset ready, let's start with it and if it turns out it will not be ready for the next release (let's hope it will) you can think again if you want to have the scan part split of to release that earlier.

It was easier to split than I thought, so I've sent the userspace
changes a minute ago:
https://lore.kernel.org/linux-wpan/20230106111831.692202-1-miquel.raynal@bootlin.com/T/#t

Thanks,
Miquèl