Hi, On Mon, 17 Jan 2022 at 06:54, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hello, > > *** TLDR *** > > Here is a series attempting to bring support for scans in the > IEEE 802.15.4 stack. A number of improvements had to be made, including: > * a better handling of the symbol durations > * a few changes in Kconfig > * a better handling of the tx queues > * a synchronous Tx API > > Active and passive scans can be locally tested only with hwsim. > > Sorry for the big series, might be split in the near future. > > ************ > > A second series aligning the tooling with these changes is related, > bringing support for a number of new features such as: > > * 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 to received BEACON_REQ. > # iwpan dev wpan0 beacons send interval 2 # send BEACON at a fixed rate > # iwpan dev wpan0 beacons send interval 15 # answer BEACON_REQ only > # iwpan dev wpan0 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 > > * If a beacon is received during a scan, the internal PAN list is > updated and can be dumped, flushed and configured with: > # iwpan dev wpan1 pans dump > PAN 0xffff (on wpan1) > coordinator 0x2efefdd4cdbf9330 > page 0 > channel 13 > superframe spec. 0xcf22 > LQI 0 > seen 7156ms ago > # iwpan dev wpan1 pans flush > # iwpan dev wpan1 set max_pan_entries 100 > # iwpan dev wpan1 set pans_expiration 3600 > > * 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 > > The PAN list gets automatically updated by dropping the expired PANs > each time the user requests access to the list. > > Internally, both requests (scan/beacons) are handled periodically by > delayed workqueues when relevant. > > So far the only technical point that is missing in this series is the > possibility to grab a reference over the module driving the net device > in order to prevent module unloading during a scan or when the beacons > work is ongoing. > > Finally, this series is a deep reshuffle of David Girault's original > work, hence the fact that he is almost systematically credited, either > by being the only author when I created the patches based on his changes > with almost no modification, or with a Co-developped-by tag whenever the > final code base is significantly different than his first proposal while > still being greatly inspired from it. > can you please split this patch series, what I see is now: 1. cleanup patches 2. sync tx handling for mlme commands 3. scan support we try to bring the patches upstream in this order. Thanks. - Alex
