lkml.org 
[lkml]   [2022]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [net-next 12/18] net: mac802154: Handle scan requests
    Hi Alexander,

    alex.aring@gmail.com wrote on Wed, 5 Jan 2022 19:38:12 -0500:

    > Hi,
    >
    >
    > On Wed, 5 Jan 2022 at 15:55, Miquel Raynal <miquel.raynal@bootlin.com> 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

    \
     
     \ /
      Last update: 2022-01-06 20:15    [W:2.291 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site