Hi, On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > 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) > 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? Does this sound okay? - Alex
