Hi, On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hi Alexander, > > aahringo@xxxxxxxxxx wrote on Sun, 28 Aug 2022 09:55:24 -0400: > > > Hi, > > > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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. > I think we should look at this, because it requires that all applications link to pthreads if we offer such an API. Any thoughts about alternative ways, can it not be done over libnl, that libnl internally used e.g. select()? The above example is only regarding the process context. > > > 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). > For me that can be already provided by the iwpan monitor command, maybe with some pretty print args or json args to have it in a nice way or json whatever looks like ip/iw thingy. :) However I don't really bother here, except that it might confuse people who want to scan and probably want the blocked command only and think the other scan commands are necessary to perform a scan... - Alex
