Hi,
On Wed, 29 Dec 2021 at 09:45, Nicolas Schodet <nico@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> * Alexander Aring <alex.aring@xxxxxxxxx> [2021-12-29 09:30]:
> > Hi,
> > On Wed, 22 Dec 2021 at 10:58, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> > ...
> > > +{
> > > + bool promiscuous_on = mac802154_check_promiscuous(local);
> > > + int ret;
> > > +
> > > + if ((state && promiscuous_on) || (!state && !promiscuous_on))
> > > + return 0;
> > > +
> > > + ret = drv_set_promiscuous_mode(local, state);
> > > + if (ret)
> > > + pr_err("Failed to %s promiscuous mode for SW scanning",
> > > + state ? "set" : "reset");
> > The semantic of promiscuous mode on the driver layer is to turn off
> > ack response, address filtering and crc checking. Some transceivers
> > don't allow a more fine tuning on what to enable/disable. I think we
> > should at least do the checksum checking per software then?
> > Sure there is a possible tune up for more "powerful" transceivers then...
>
> In this case, the driver could change the (flags &
> IEEE802154_HW_RX_DROP_BAD_CKSUM) bit dynamically to signal it does not
> check the checksum anymore. Would it work?
I think that would work, although the intention of the hw->flags is to
define what the hardware is supposed to support as not changing those
values dynamically during runtime so mac will care about it. However
we don't expose those flags to the userspace, so far I know. We can
still introduce two separated flags if necessary in future.
Why do we need promiscuous mode at all? Why is it necessary for a
scan? What of "ack response, address filtering and crc checking" you
want to disable and why?
I see that beacons are sent out with
"local->beacon.mhr.fc.dest_addr_mode = IEEE802154_NO_ADDRESSING;"
shouldn't that be a broadcast destination?
- Alex
