Hi Alexander,

aahringo@redhat.com wrote on Wed, 24 Aug 2022 21:02:29 -0400:

Hi,

On Wed, Aug 24, 2022 at 5:53 PM Alexander Aring [off-list ref] wrote:

quoted

Hi,

On Wed, Aug 24, 2022 at 9:27 AM Miquel Raynal [off-list ref] wrote:  

quoted

Hi Alexander,

aahringo@redhat.com wrote on Wed, 24 Aug 2022 08:43:20 -0400:
 

quoted

Hi,

On Wed, Aug 24, 2022 at 6:21 AM Miquel Raynal [off-list ref] wrote:
...  

quoted

Actually right now the second level is not enforced, and all the
filtering levels are a bit fuzzy and spread everywhere in rx.c.

I'm gonna see if I can at least clarify all of that and only make
coord-dependent the right section because right now a
ieee802154_coord_rx() path in ieee802154_rx_handle_packet() does not
really make sense given that the level 3 filtering rules are mostly
enforced in ieee802154_subif_frame().  

One thing I mentioned before is that we probably like to have a
parameter for rx path to give mac802154 a hint on which filtering
level it was received. We don't have that, I currently see that this
is a parameter for hwsim receiving it on promiscuous level only and
all others do third level filtering.
We need that now, because the promiscuous mode was only used for
sniffing which goes directly into the rx path for monitors. With scan
we mix things up here and in my opinion require such a parameter and
do filtering if necessary.  

I am currently trying to implement a slightly different approach. The
core does not know hwsim is always in promiscuous mode, but it does
know that it does not check FCS. So the core checks it. This is
level 1 achieved. Then in level 2 we want to know if the core asked
the transceiver to enter promiscuous mode, which, if it did, should
not imply more filtering. If the device is working in promiscuous
mode but this was not asked explicitly by the core, we don't really
care, software filtering will apply anyway.
 

I doubt that I will be happy with this solution, this all sounds like
"for the specific current behaviour that we support 2 filtering levels
it will work", just do a parameter on which 802.15.4 filtering level
it was received and the rx path will check what kind of filter is  

I think a per phy field is enough here because the receive path should
be synchronized with changing filtering level on hardware. No need for
per receive path parameter.

Ok, I prefer the per-PHY field rather than the per-received-skb info.

I will add a parameter in the start field set to LEVEL3, drivers are
free to change this (like hwsim) if they can't.

I will add also the major filtering rules in the rx path but we will
actually use them only if the hw filtering level is lower than what is
requested, as you said.

"If the device is working in promiscuous mode but this was not asked
explicitly by the core, we don't really care, software filtering will
apply anyway."
I don't understand this sentence, we should not filter on things which
the hardware is doing for us. I mean okay I'm fine to handle it now
just to check twice, but in the future there might be more "we don't
need to filter this because we know the hardware is doing it" patches.

- Alex

Thanks,
Miquèl