netdev - Re: [PATCH wpan-next 2/5] mac802154: Use the PAN coordinator parameter when stamping packets

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]

Date: Thu, 14 Dec 2023 21:46:06 -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 2/5] mac802154: Use the PAN coordinator
 parameter when stamping packets

Hi,

On Tue, Nov 28, 2023 at 6:17 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> ACKs come with the source and destination address empty, this has been
> clarified already. But there is something else: if the destination
> address is empty but the source address is valid, it may be a way to
> reach the PAN coordinator. Either the device receiving this frame is the
> PAN coordinator itself and should process what it just received
> (PACKET_HOST) or it is not and may, if supported, relay the packet as it
> is targeted to another device in the network.
>
> Right now we do not support relaying so the packet should be dropped in
> the first place, but the stamping looks more accurate this way.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> ---
>  net/mac802154/rx.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
> index 0024341ef9c5..e40a988d6c80 100644
> --- a/net/mac802154/rx.c
> +++ b/net/mac802154/rx.c
> @@ -156,12 +156,15 @@ ieee802154_subif_frame(struct ieee802154_sub_if_data *sdata,
>
>         switch (mac_cb(skb)->dest.mode) {
>         case IEEE802154_ADDR_NONE:
> -               if (hdr->source.mode != IEEE802154_ADDR_NONE)
> -                       /* FIXME: check if we are PAN coordinator */
> -                       skb->pkt_type = PACKET_OTHERHOST;
> -               else
> +               if (hdr->source.mode == IEEE802154_ADDR_NONE)
>                         /* ACK comes with both addresses empty */
>                         skb->pkt_type = PACKET_HOST;
> +               else if (!wpan_dev->parent)
> +                       /* No dest means PAN coordinator is the recipient */
> +                       skb->pkt_type = PACKET_HOST;
> +               else
> +                       /* We are not the PAN coordinator, just relaying */
> +                       skb->pkt_type = PACKET_OTHERHOST;
>                 break;
>         case IEEE802154_ADDR_LONG:
>                 if (mac_cb(skb)->dest.pan_id != span &&

So if I understand it correctly, the "wpan_dev->parent" check acts
like a "forwarding" setting on an IP capable interface here? The
"forwarding" setting changes the interface to act as a router, which
is fine... but we have a difference here with the actual hardware and
the address filtering setting which we don't have in e.g. ethernet. My
concern is here that this code is probably interface type specific,
e.g. node vs coordinator type and currently we handle both in one
receive part.

I am fine with that and probably it is just a thing to change in future...

- Alex