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? - Alex
