Hi, On Wed, Sep 21, 2022 at 11:49 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hi Alexander, > > aahringo@xxxxxxxxxx wrote on Thu, 8 Sep 2022 20:49:36 -0400: > > > Hi, > > > > On Mon, Sep 5, 2022 at 4:34 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > > > 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
