From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Aring <aahringo@redhat.com>
Cc: Alexander Aring <alex.aring@gmail.com>,
Stefan Schmidt <stefan@datenfreihafen.org>,
linux-wpan@vger.kernel.org,
David Girault <david.girault@qorvo.com>,
Romuald Despres <romuald.despres@qorvo.com>,
Frederic Blain <frederic.blain@qorvo.com>,
Nicolas Schodet <nico@ni.fr.eu.org>,
Guilhem Imberton <guilhem.imberton@qorvo.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH wpan-next 2/5] mac802154: Use the PAN coordinator parameter when stamping packets
Date: Fri, 15 Dec 2023 11:42:28 +0100 [thread overview]
Message-ID: <20231215114228.35e3a408@xps-13> (raw)
In-Reply-To: <CAK-6q+jpmhhARPcjkbfFVR7tRFQqYwXAdngebyUt+BzpFcgUGw@mail.gmail.com>
Hi Alexander,
aahringo@redhat.com wrote on Thu, 14 Dec 2023 21:46:06 -0500:
> Hi,
>
> On Tue, Nov 28, 2023 at 6:17 AM Miquel Raynal <miquel.raynal@bootlin.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@bootlin.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
Kind of, yes, in this case having a parent means we are not the top
level PAN coordinator.
> "forwarding" setting changes the interface to act as a router, which
> is fine...
I think there is no true "router" role but depending on the frame
construction (dest field) we might sometimes act as a router. This is
not supported in Linux, just a feature of the spec.
> 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...
That is true and probably will need adaptations if/when we come to this
feature. What we do here however is just stamping the packet, in a
manner that is more accurate. So in practice all type of interfaces may
want to do that. However the handling of the packet later in the
stack will be interface specific, I agree.
Thanks,
Miquèl
next prev parent reply other threads:[~2023-12-15 10:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 11:16 [PATCH wpan-next 0/5] ieee802154: Association tweaks Miquel Raynal
2023-11-28 11:16 ` [PATCH wpan-next 1/5] mac80254: Provide real PAN coordinator info in beacons Miquel Raynal
2023-12-07 20:42 ` Stefan Schmidt
2023-12-15 3:06 ` Alexander Aring
2023-12-20 7:32 ` Miquel Raynal
2023-11-28 11:16 ` [PATCH wpan-next 2/5] mac802154: Use the PAN coordinator parameter when stamping packets Miquel Raynal
2023-12-07 20:44 ` Stefan Schmidt
2023-12-15 2:46 ` Alexander Aring
2023-12-15 3:05 ` Alexander Aring
2023-12-15 10:42 ` Miquel Raynal [this message]
2023-12-20 7:32 ` Miquel Raynal
2023-11-28 11:16 ` [PATCH wpan-next 3/5] mac802154: Only allow PAN controllers to process association requests Miquel Raynal
2023-12-07 20:45 ` Stefan Schmidt
2023-12-15 3:17 ` Alexander Aring
2023-12-20 7:32 ` Miquel Raynal
2023-11-28 11:16 ` [PATCH wpan-next 4/5] ieee802154: Avoid confusing changes after associating Miquel Raynal
2023-12-07 20:47 ` Stefan Schmidt
2023-12-15 3:18 ` Alexander Aring
2023-12-20 7:32 ` Miquel Raynal
2023-11-28 11:16 ` [PATCH wpan-next 5/5] mac802154: Avoid new associations while disassociating Miquel Raynal
2023-12-07 20:49 ` Stefan Schmidt
2023-12-15 3:19 ` Alexander Aring
2023-12-20 7:32 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231215114228.35e3a408@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=aahringo@redhat.com \
--cc=alex.aring@gmail.com \
--cc=davem@davemloft.net \
--cc=david.girault@qorvo.com \
--cc=edumazet@google.com \
--cc=frederic.blain@qorvo.com \
--cc=guilhem.imberton@qorvo.com \
--cc=kuba@kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nico@ni.fr.eu.org \
--cc=pabeni@redhat.com \
--cc=romuald.despres@qorvo.com \
--cc=stefan@datenfreihafen.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox