Hi,

On Wed, Sep 21, 2022 at 11:49 AM Miquel Raynal
[off-list ref] wrote:

Hi Alexander,

aahringo@redhat.com wrote on Thu, 8 Sep 2022 20:49:36 -0400:

quoted

Hi,

On Mon, Sep 5, 2022 at 4:34 PM Miquel Raynal [off-list ref] wrote:

quoted

This IEEE802154_HW_RX_DROP_BAD_CKSUM flag was only used by hwsim to
reflect the fact that it would not validate the checksum (FCS). In other
words, the filtering level of hwsim is always "NONE" while the core
expects it to be higher.

Now that we have access to real filtering levels, we can actually use
them and always enforce the "NONE" level in hwsim. This case is already
correctly handled in the receive so we can drop the flag.

I would say the whole hwsim driver currently only works because we
don't transmit wrong frames on a virtual hardware... However this can
be improved, yes. In my opinion the hwsim driver should pretend to
work like other transceivers sending frames to mac802154. That means
the filtering level should be implemented in hwsim not in mac802154 as
on real hardware the hardware would do filtering.

I think you should assume for now the previous behaviour that hwsim
does not send bad frames out. Of course there is a bug but it was
already there before, but the fix would be to change hwsim driver.

Well, somehow I already implemented all the filtering by software in
one of the other patches. I now agree that it was not relevant (because
of the AACK issue you raised), but instead of fully dropping this code
I might just move it to hwsim because there it would perfectly make
sense?

Yes, I agree. You should make the "in-driver receive path" acting like
other hardware (In sense what we currently agree on what filtering
they do) if promiscuous mode is turned off/on.

It makes sense and should be done there. The
IEEE802154_HW_RX_DROP_BAD_CKSUM flag should still be dropped.

- Alex