netdev - Re: [PATCH wpan-next v2 6/6] 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+hJb-py2sNBGYBQeHLbyM_OWzi78-gOf0LcdTukFDO4MQ@mail.gmail.com>
Date:   Mon, 2 Jan 2023 20:04:18 -0500
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@...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>,
        Guilhem Imberton <guilhem.imberton@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org
Subject: Re: [PATCH wpan-next v2 6/6] mac802154: Handle passive scanning

Hi,

On Fri, Dec 16, 2022 at 7:04 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
...
> +void mac802154_scan_worker(struct work_struct *work)
> +{
> +       struct ieee802154_local *local =
> +               container_of(work, struct ieee802154_local, scan_work.work);
> +       struct cfg802154_scan_request *scan_req;
> +       struct ieee802154_sub_if_data *sdata;
> +       unsigned int scan_duration = 0;
> +       struct wpan_phy* wpan_phy;
> +       u8 scan_req_duration;
> +       u8 page, channel;
> +       int ret;
> +
> +       /* Ensure the device receiver is turned off when changing channels
> +        * because there is no atomic way to change the channel and know on
> +        * which one a beacon might have been received.
> +        */
> +       drv_stop(local);
> +       synchronize_net();

Do we do that for every channel switch? I think this is not necessary.
It is necessary for bringing the transceiver into scan filtering mode,
but we don't need to do that for switching the channel.

And there is a difference why we need to do that for filtering. In my
mind I had the following reason that the MAC layer is handled in Linux
(softMAC) and by offloaded parts on the transceiver, this needs to be
synchronized. The PHY layer is completely on the transceiver side,
that's why you can switch channels during interface running. There
exist some MAC parameters which are offloaded to the hardware and are
currently not possible to synchronize while an interface is up,
however this could change in future because the new helpers to
synchronize softmac/transceiver mac handling.

There is maybe a need here to be sure everything is transmitted on the
hardware before switching the channel, but this should be done by the
new mlme functionality which does a synchronized transmit. However we
don't transmit anything here, so there is no need for that yet. We
should never stop the transceiver being into receive mode and during
scan we should always be into receive mode in
IEEE802154_FILTERING_3_SCAN level without never leaving it.

... and happy new year.

I wanted to ack this series but this came into my mind. I also wanted
to check what exactly happens when a mlme op returns an error like
channel access failure? Do we ignore it? Do we do cond_resched() and
retry again later? I guess these are questions only if we get into
active scanning with more exciting sending of frames, because here we
don't transmit anything.

- Alex