Message-ID: <20220903180556.6430194b@xps-13>
Date:   Sat, 3 Sep 2022 18:05:56 +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,

aahringo@...hat.com wrote on Sat, 3 Sep 2022 10:20:24 -0400:

> Hi,
> 
> On Fri, Sep 2, 2022 at 8:08 PM Miquel Raynal <miquel.raynal@...tlin.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?

I observe something very weird:

A/ If at start up time we set promisc_mode(true) and then we set the hw
address filters, all the frames are forwarded to the MAC.

B/ If at start up time we set the hw address filters and then set
promisc_mode(true), there is some filtering happening (like the Acks
which are dropped by the PHY.

I need to investigate this further because I don't get why in case B we
don't have the same behavior than in case A.

> > 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).

Yes, but when sending MAC frames I would like to:
- be in promiscuous mode in Rx (tx paused) in order for the MAC to be
  aware of the acks being received (unless there is another way to do
  that, see below)
- still ack the received frames automatically

Unless we decide that we must only ack the expected frames manually?

> > 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.

Absolutely (for the record, that's also an issue I had with Zephyr, I
had to use the shell to explicitly ask the AR bit to be set in the
outgoing frames, even though this in most MAC frames this is not a user
choice, it's expected by the spec).

> 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.

On the Tx side, when sending eg. an association request or an
association response, I must expect and wait for an ack. This is
what I am struggling to do. How can I know that a frame which I just
transmitted has been acked? Bonus points, how can I do that in such a
way that it will work with other devices? (hints below)

> 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.

:'(

Let's say I don't have the time to update the firmware ;). I also assume
that other transceivers (or even the drivers) might be limited on this
regard as well. How should I handle those "I should wait for the ack to
be received" situation while trying to associate?

The tricky case is the device receiving the ASSOC_REQ:
- the request is received
- an ack must be sent (this is okay in most cases I guess)
- the device must send an association response (also ok)
- and wait for the response to be acked...
	* either I use the promisc mode when sending the response
	  (because of possible race conditions) and I expect the ack to
	  be forwarded to the MAC
		-> This does not work on atusb, enabling promiscuous
		mode after the init does not turn the PHY into
		promiscuous mode as expected (discussed above)
	* or I don't turn the PHY in promiscuous mode and I expect it
	  to return a clear status about if the ACK was received
		-> But this seem to be unsupported with the current
		ATUSB firmware, I fear other devices could have similar
		limitations
	* or I just assume the acks are received blindly
		-> Not sure this is robust enough?

What is your "less worse" choice?

> Btw: I can imagine that hwsim "fakes" such
> offload behaviours.

My current implementation actually did handle all the acks (waiting for
them and sending them) from the MAC. I'm currently migrating the ack
sending part to the hw. For the reception, that's the big question.

> > 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"?

If we have access to the TRAC register, I believe we no longer need to
turn off address filters.

> 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
> 


Thanks,
Miquèl

Powered by blists - more mailing lists