netdev - Re: [PATCH wpan-next 01/20] net: mac802154: Allow the creation of coordinator interfaces

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: <20220831173903.1a980653@xps-13>
Date:   Wed, 31 Aug 2022 17:39:03 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <aahringo@...hat.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 01/20] net: mac802154: Allow the creation of
 coordinator interfaces

Hi Alexander & Stefan,

aahringo@...hat.com wrote on Mon, 29 Aug 2022 22:23:09 -0400:

I am currently testing my code with the ATUSB devices, the association
works, so it's a good news! However I am struggling to get the
association working for a simple reason: the crafted ACKs are
transmitted (the ATUSB in monitor mode sees it) but I get absolutely
nothing on the receiver side.

The logic is:

coord0                 coord1
association req ->
                <-     ack
                <-     association response
ack             ->

The first ack is sent by coord1 but coord0 never sees anything. In
practice coord0 has sent an association request and received a single
one-byte packet in return which I guess is the firmware saying "okay, Tx
has been performed". Shall I interpret this byte differently? Does it
mean that the ack has also been received? 

I could not find a documentation of the firmware interface, I went
through the wiki but I did not find something clear about what to
expect or "what the driver should do". But perhaps this will ring a
bell on your side?

[...]

> I did not see the v2 until now. Sorry for that.

Ah! Ok, no problem :)

> 
> However I think there are missing bits here at the receive handling
> side. Which are:
> 
> 1. Do a stop_tx(), stop_rx(), start_rx(filtering_level) to go into
> other filtering modes while ifup.

Who is supposed to change the filtering level?

For now there is only the promiscuous mode being applied and the user
has no knowledge about it, it's just something internal.

Changing how the promiscuous mode is applied (using a filtering level
instead of a "promiscuous on" boolean) would impact all the drivers
and for now we don't really need it.

> I don't want to see all filtering modes here, just what we currently
> support with NONE (then with FCS check on software if necessary),
> ?THIRD/FOURTH? LEVEL filtering and that's it. What I don't want to see
> is runtime changes of phy flags. To tell the receive path what to
> filter and what's not.

Runtime changes on a dedicated "filtering" PHY flag is what I've used
and it works okay for this situation, why don't you want that? It
avoids the need for (yet) another rework of the API with the drivers,
no?

> 2. set the pan coordinator bit for hw address filter. And there is a
> TODO about setting pkt_type in mac802154 receive path which we should
> take a look into. This bit should be addressed for coordinator support
> even if there is the question about coordinator vs pan coordinator,
> then the kernel needs a bit as coordinator iface type parameter to
> know if it's a pan coordinator and not coordinator.

This is not really something that we can "set". Either the device
had performed an association and it is a child device: it is not the
PAN coordinator, or it initiated the PAN and it is the PAN coordinator.
There are commands to change that later on but those are not supported.

The "PAN coordinator" information is being added in the association
series (which comes after the scan). I have handled the pkt_type you are
mentioning.

> I think it makes total sense to split this work in transmit handling,
> where we had no support at all to send something besides the usual
> data path, and receive handling, where we have no way to change the
> filtering level besides interface type and ifup time of an interface.
> We are currently trying to make a receive path working in a way that
> "the other ideas flying around which are good" can be introduced in
> future.
> If this is done, then take care about how to add the rest of it.
> 
> I will look into v2 the next few days.
> 
> - Alex
> 

Thanks,
Miquèl