sorry for the big delay. NETOPT_ACK_REQ, NETOPT_AUTOACK as well as
NETOPT_RETRANS, NETOPT_CSMA or NETOPT_CSMA_RETRIES are not meant to be
called each time before a frame-transmission but just to set the option
on the device/driver. That means -if set- the driver will set the ACK
REQ bit automatically for each frame it sends.
Am 14.09.2016 um 10:25 schrieb Alexander Aring:
On 09/13/2016 11:31 PM, Peter Kietzmann wrote:
It confuses me a little bit here, does such netdev2 option exists to
disable auto-acknowledgement or not? For me it should always depends
on the acknowledgement-request bit in fc field.
have a look at this PR:
I agree with you that (except in promiscuous sniffer mode) the ACK of a receiver should
depend on the ACK request field of the received frame which will be handled by the
hardware (in case AACK is not disabled). IIRC "NETOPT_AUTOACK" once was meant
to handle the ACK request of a transmitter but the name was a bit misleading.
okay, but why does this setting reach the driver layer, or does it not?
The driver(or in case of at86rf2xx the hardware) should check if the
acknowledgement-request bit is set or not and this _per_ _frame_ and
prepare transceiver to do ARET handling if it's set (maybe inside the
transmit callback of driver layer).
Or will the NETOPT_ACK_REQ option called each time before transmit to
signal the fc acknowledgement-request bit? This confuse me then with the
at86rf2xx hardware which will do ARET handling or not at hardware side
by checking fc acknowledgement-request bit setting in fc.
Such setting should only reach the mac layer, which controls then the
frame control field generation of 802.15.4 dataframes, in my opinion.
The transceiver should has some per frame decision if doing ARET or not
ARET handling before transmit, or do nothing e.g. at86rf2xx because the
hardware does that check.
(sniffer) I think our handling in Linux is to let ARET enabled but
disable AACK handling. AACK handling without address filtering will
occur that you ack mostly every frame which will arrived. :-)
devel mailing list
Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
devel mailing list