Hi Alexander, aahringo@xxxxxxxxxx wrote on Thu, 25 Aug 2022 21:22:48 -0400: > Hi, > > On Thu, Aug 25, 2022 at 8:55 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > Hi Alexander, > > > > aahringo@xxxxxxxxxx wrote on Tue, 23 Aug 2022 21:36:23 -0400: > > > > > 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? > > > > 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
