| Message ID | 20220701143434.1267864-1-miquel.raynal@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iwpan: Support scanning/beaconing | expand |
Hi, On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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
Hi, On Sun, Jul 3, 2022 at 9:18 PM Alexander Aring <aahringo@redhat.com> wrote: > > Hi, > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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? I'm still thinking about it. Is done a kind of "block until scan is done", but isn't this an event to signal when the mac operation is done? What is the difference between done and abort, is this not just "end" as I don't want to be in scan mode anymore (because we block all interface traffic during this time)? - Alex
Hi Alexander, aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400: > Hi, > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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
Hi, On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400: > > > Hi, > > > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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
Hi Alexander, aahringo@redhat.com wrote on Tue, 23 Aug 2022 21:36:23 -0400: > Hi, > > On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400: > > > > > Hi, > > > > > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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") - 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. Do you want something more? I just miss a "monitor" command I guess, I may add it. Thanks, Miquèl
Hi, On Thu, Aug 25, 2022 at 8:55 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > aahringo@redhat.com wrote on Tue, 23 Aug 2022 21:36:23 -0400: > > > Hi, > > > > On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > Hi Alexander, > > > > > > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400: > > > > > > > Hi, > > > > > > > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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. > - 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. - Alex
Hi Alexander, aahringo@redhat.com wrote on Thu, 25 Aug 2022 21:22:48 -0400: > Hi, > > On Thu, Aug 25, 2022 at 8:55 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > aahringo@redhat.com wrote on Tue, 23 Aug 2022 21:36:23 -0400: > > > > > Hi, > > > > > > On Fri, Aug 19, 2022 at 1:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > Hi Alexander, > > > > > > > > aahringo@redhat.com wrote on Sun, 3 Jul 2022 21:18:40 -0400: > > > > > > > > > Hi, > > > > > > > > > > On Fri, Jul 1, 2022 at 10:39 AM Miquel Raynal <miquel.raynal@bootlin.com> 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
Hi, On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> 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". > 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", "monitor" will give you all 802.15.4 events, scan will give you a filter for all scan events and may we add in future even a ?phy/dev? argument to filter per interface? :) "monitor scan" just to move event monitoring to the right command. - Alex
Hi Alexander, aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400: > Hi, > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> 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. > > 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). > "monitor" will give you all 802.15.4 events, scan will give you a > filter for all scan events and may we add in future even a ?phy/dev? > argument to filter per interface? :) > > "monitor scan" just to move event monitoring to the right command. I haven't added the "scan" option because we currently have almost only that, it can be added later, it's just a tool to show how everything works and give a code base anyway. Thanks, Miquèl
Hi, On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400: > > > Hi, > > > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> 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
Hi, On Mon, Aug 29, 2022 at 8:57 AM Alexander Aring <aahringo@redhat.com> wrote: > > Hi, > > On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400: > > > > > Hi, > > > > > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> 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. > I think pthreads are not necessary here. If we don't close and open the nl socket everything should be queued. Forget that with select(), just send() and recv() (whatever that is underneath of libnl) should be enough. - Alex
Hi Alexander, aahringo@redhat.com wrote on Tue, 30 Aug 2022 23:17:35 -0400: > Hi, > > On Mon, Aug 29, 2022 at 8:57 AM Alexander Aring <aahringo@redhat.com> wrote: > > > > Hi, > > > > On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > Hi Alexander, > > > > > > aahringo@redhat.com wrote on Sun, 28 Aug 2022 09:55:24 -0400: > > > > > > > Hi, > > > > > > > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@bootlin.com> 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. > > > > I think pthreads are not necessary here. If we don't close and open > the nl socket everything should be queued. > Forget that with select(), just send() and recv() (whatever that is > underneath of libnl) should be enough. That's way more clever. I've changed that, no more pthread and no more race, thanks! Thanks, Miquèl