Hi, On Mon, Aug 1, 2022 at 7:42 PM Alexander Aring <aahringo@xxxxxxxxxx> wrote: > > Hi, > > On Thu, Jul 14, 2022 at 11:33 PM Alexander Aring <aahringo@xxxxxxxxxx> wrote: > ... > > > > I know some driver datasheets and as I said before, it's not allowed > > to set promiscuous mode while in receive mode. We need to stop tx, > > what we are doing. Then call stop() driver callback, > > synchronize_net(), mac802154_set_promiscuous_mode(...), start(). The > > same always for the opposite. > > > > I think we should try to work on that as a next patch series to offer > such functionality in which "filtering level" the hardware should be > "started". As I said it cannot be changed during runtime as > "transceiver is being in receive mode" but there is the possibility to > stop/start the hardware _transparent_ from the user to change the > "filtering level". I say filtering level because I think this is what > the standard uses as a term. The one which is needed here is > promiscuous mode, otherwise yea we usually use the highest filtering > level. When changing the "filtering level" it depends on interface > type what we need to filter in softmac then and what's not. One thing > in promiscuous mode and everything else than monitor is to check on if > the checksum is valid and drop if necessary, same for address > filtering, etc. I don't assume that the software filtering is 100% forget the address filtering, this is only required when it operates in non scan mode. It always depends, however you don't need to implement it if it's not necessary. I think we should somehow get a per parameter at receive path to know on which filtering level it was received, then more handling in regarding which receive path it goes can be made, e.g. if frame xy was received in promiscuous mode. For scan you don't need to check address filter but checksum, other receive path have different requirements (not saying that those exists right now but may in future). - Alex
