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

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

Hi Alexander,

aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400:

> Hi,
> 
> On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> ...
> >
> > 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  
> 
> no, there is a race in the design of "scan trigger; scan monitor".

Right, I've used pthread to first start the monitoring, before actually
triggering the scan. That should be enough.

> >   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.  
> 
> I would remove the scan monitor and if it is needed a "monitor scan",

Actually we need both "scan monitor" and "monitor scan". The former
shows what is happening in a clean manner, with a detailed view of all
the information about the beacon received, while the latter would more
something that we run aside to follow what's happening, it's a bare and
short output (one-liners).

> "monitor" will give you all 802.15.4 events, scan will give you a
> filter for all scan events and may we add in future even a ?phy/dev?
> argument to filter per interface? :)
> 
> "monitor scan" just to move event monitoring to the right command.

I haven't added the "scan" option because we currently have almost only
that, it can be added later, it's just a tool to show how everything
works and give a code base anyway.

Thanks,
Miquèl