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

From: Alexander Aring <aahringo@redhat.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Alexander Aring <alex.aring@gmail.com>,
	Stefan Schmidt <stefan@datenfreihafen.org>,
	linux-wpan - ML <linux-wpan@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Network Development <netdev@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>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH wpan-next 01/20] net: mac802154: Allow the creation of coordinator interfaces
Date: Sat, 3 Sep 2022 10:20:24 -0400	[thread overview]
Message-ID: <CAK-6q+hO1i=xvXx3wHo658ph93FwuVs_ssjG0=jnphEe8a+gxw@mail.gmail.com> (raw)
In-Reply-To: <20220903020829.67db0af8@xps-13>

Hi,

On Fri, Sep 2, 2022 at 8:08 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
...
> >
> > I am sorry, I never looked into Zephyr for reasons... Do they not have
> > something like /proc/interrupts look if you see a counter for your
> > 802.15.4 transceiver?
> >
> > > Also, can you please clarify when are we talking about software and
> > > when about hardware filters.
> > >
> >
> > Hardware filter is currently e.g. promiscuous mode on or off setting.
> > Software filtering is depending which receive path the frame is going
> > and which hardware filter is present which then acts like actually
> > with hardware filtering.
> > I am not sure if this answers this question?
>
> I think my understand gets clearer now that I've digged into Zephyr's
> ieee802154 layer and in the at86rf230 datasheet.
>

okay, I think for zephyr questions you are here on the wrong mailinglist.

> I will answer the previous e-mail but just for not I wanted to add that
> I managed to get Zephyr working, I had to mess around in the code a
> little bit and actually I discovered a net command which is necessary
> to use in order to turn the iface up, whatever.
>

aha.

> So I was playing with the atusb devices and I _think_ I've found a
> firmware bug or a hardware bug which is going to be problematic. In

the firmware is open source, I think it's fine to send patches here (I
did it as well once for do a quick hack to port it to rzusb) the atusb
is "mostly" at the point that they can do open hardware from the
qi-hardware organization.

> iface.c, when creating the interface, if you set the hardware filters
> (set_panid/short/ext_addr()) there is no way you will be able to get a
> fully transparent promiscuous mode. I am not saying that the whole

What is a transparent promiscuous mode?

> promiscuous mode does not work anymore, I don't really know. What I was
> interested in were the acks, and getting them is a real pain. At least,
> enabling the promiscuous mode after setting the hw filters will lead to
> the acks being dropped immediately while if the promiscuous mode is
> enabled first (like on monitor interfaces) the acks are correctly
> forwarded by the PHY.

If we would not disable AACK handling (means we receive a frame with
ack requested bit set we send a ack back) we would ack every frame it
receives (speaking on at86rf233).

>
> While looking at the history of the drivers, I realized that the
> TX_ARET mode was not supported by the firmware in 2015 (that's what you

There exists ARET and AACK, both are mac mechanisms which must be
offloaded on the hardware. Note that those only do "something" if the
ack request bit in the frame is set.

ARET will retransmit if no ack is received after some while, etc.
mostly coupled with CSMA/CA handling. We cannot guarantee such timings
on the Linux layer. btw: mac80211 can also not handle acks on the
software layer, it must be offloaded.

AACK will send a back if a frame with ack request bit was received.

> say in a commit) I have seen no further updates about it so I guess
> it's still not available. I don't see any other way to know if a
> frame's ack has been received or not reliably.

You implemented it for the at86rf230 driver (the spi one which is what
also atusb uses). You implemented the

ctx->trac = IEEE802154_NO_ACK;

which signals the upper layer that if the ack request bit is set, that
there was no ack.

But yea, there is a missing feature for atusb yet which requires
firmware changes as well. Btw: I can imagine that hwsim "fakes" such
offload behaviours.

>
> Do you think I can just ignore the acks during an association in
> mac802154?

No, even we should WARN_ON ack frames in states we don't expect them
because they must be offloaded on hardware.

I am not sure if I am following what is wrong with the trac register
and NO_ACK, this is the information if we got an ack or not. Do you
need to turn off address filters while "an association"?

Another idea how to get them? The Atmel datasheet states the
> following, which is not encouraging:
>
>         If (Destination Addressing Mode = 0 OR 1) AND (Source
>         Addressing Mode = 0) no IRQ_5 (AMI) is generated, refer to
>         Section 8.1.2.2 “Frame Control Field (FCF)” on page 80. This
>         effectively causes all acknowledgement frames not to be
>         announced, which otherwise always pass the fil- ter, regardless
>         of whether they are intended for this device or not.

I hope the answers above are helpful because I don't know how this can
be useful here.

- Alex