netdev - Re: [PATCH wpan-next 10/20] net: mac802154: Handle passive scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK-6q+ihyGycUAOcF-UWs49YAtJi3so-aaRAodsD6ikxuhpX=Q@mail.gmail.com>
Date:   Mon, 1 Aug 2022 19:54:22 -0400
From:   Alexander Aring <aahringo@...hat.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Network Development <netdev@...r.kernel.org>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next 10/20] net: mac802154: Handle passive scanning

Hi,

On Mon, Aug 1, 2022 at 7:42 PM Alexander Aring <aahringo@...hat.com> wrote:
>
> Hi,
>
> On Thu, Jul 14, 2022 at 11:33 PM Alexander Aring <aahringo@...hat.com> 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