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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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