Hi Alexander, alex.aring@xxxxxxxxx wrote on Wed, 5 Jan 2022 19:38:12 -0500: > Hi, > > > On Wed, 5 Jan 2022 at 15:55, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > ... > > > rest in software is a bigger task here... > > > > On the symbol duration side I feel I'm close to a working PoC. > > > > oh, ok. I think it's ready, I'll soon send two series: - the symbol duration update - v2 for this series, which will not apply without the symbol duration update. > > So there is 'only' this item left in my mind. Could you please clarify > > what you expect from me exactly in terms of support for the promiscuous > > filters we discussed so far? > > > > I think for now it's okay to set the device into promiscuous mode and > enable the flag which checks for bad FCS... we can still implement the > filter modes later (and I think it should work on all supported > transceivers (except that SoftMAC/HardMAC thing)). I considered the following options in order to do that: 1- Hack all ->set_promiscuous() driver implementations to set IEEE802154_HW_RX_DROP_BAD_CKSUM as long as it was not already set initially. 2- Set the above flag at scan level, ie. in scan.c:mac802154_set_promiscuous_mode(). But this would be a bit ugly and I'd need to add a persistent field somewhere in the wpan_dev structure to remember how the flags settings where before the scan code hacked it. 3- Add more code in hwsim to handle checksum manually instead of by default setting the above flag to request the core to do the job. This way no driver would actually set this flag. We can then consider it "volatile" and would not need to track its state. 4- We know that we are in a scan thanks to a mac802154 internal variable, we can just assume that all drivers are in promiscuous mode and that none of them actually checks the FCS. This is certainly the simplest yet effective solution. In the worst case, we are just doing the check twice, which I believe does not hurt as long as the checksum is not cut off. If the checksum is cut, then the core is buggy because it always remove the two last bytes. I picked 4 for now, but if you think this is unreliable, please tell me what do you prefer otherwise. > One point to promiscuous mode, currently we have a checking for if a > phy is in promiscuous mode on ifup and it would forbid to ifup a node > interface if the phy is in promiscuous mode (because of the missing > automatic acknowledgement). I see there is a need to turn the phy into > promiscuous mode during runtime... so we need somehow make sure the > constraints are still valid here. Yes, the code (rx.c) currently drops everything that is not a beacon during a scan. > Maybe we even forbid multiple devs > on a phy if the transceiver/driver/firmware is poor and this is > currently all transceivers (except hwsim? But that doesn't use any ack > handling anyway). Thanks, Miquèl
