Hi Alexander,
aahringo@xxxxxxxxxx wrote on Sun, 3 Jul 2022 21:18:40 -0400:
> Hi,
>
> On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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)
Thanks,
Miquèl
