Netdev2 - Events/Flags wich cause netdev2 to transmit

Development archive
#1

Hello RIOT radio chip driver developers,

my radio module driver (work in progress) transmits Acknowledgement-Frames without forcing it to do anything. There must be a wrong condition (e.g. event or flags) in the interface between netdev2 and the hardware dependent part of the driver which forces the driver to fill the transmit buffer and send it.

Can anyone give me a hint where to search for the place where netdev2 is triggered to fill the tx-buffer and send the frame ( I guess an Ack-Frame)?

This are the first bytes inside my transmit buffer which were forced to be send:

transmitbuf[0]= 0x1f transmitbuf[1]= 0x41 transmitbuf[2]= 0x98 transmitbuf[3]= 0x0 transmitbuf[4]= 0x23 transmitbuf[5]= 0x0 transmitbuf[6]= 0xff transmitbuf[7]= 0xff transmitbuf[8]= 0x2 transmitbuf[9]= 0x30 transmitbuf[a]= 0x7b transmitbuf[b]= 0x3b transmitbuf[c]= 0x3a transmitbuf[d]= 0x2 transmitbuf[e]= 0x85 transmitbuf[f]= 0x0 e.g.

Thanks a lot,

Regards, Neo

#2

Hi Neo,

Hello RIOT radio chip driver developers,

my radio module driver (work in progress) transmits Acknowledgement-Frames without forcing it to do anything.

Can you rephrase please? 802.15.4 ACK frames are generated by the hardware and not triggered by the network stack (they where sent by the radio after a valid 802.15.4 frame was received in which the ACK request bit is set). You can enable/disable this behaviour in the RXMCR register of the mrf24j40. The netdev2 provides an interface to set options (netopts). The NETOPT_AUTOACK option should be implemented by your driver to set this option on the device (didn't check your driver until now).

https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/netopt.h#L91

There must be

a wrong condition (e.g. event or flags) in the interface between netdev2 and the hardware dependent part of the driver which forces the driver to fill the transmit buffer and send it.

Which application code did you use? Some time ago you wondered about additional packets sent by layer 3. When exactly do you observe this packet? Do you have a possibility for sniffing the wireless traffic? E.g. A RasPi plus the mrf24j40 should do it.

Can anyone give me a hint where to search for the place where netdev2 is triggered to fill the tx-buffer and send the frame ( I guess an Ack-Frame)?

As said, there is not ACK frame transmission triggered by netdev. In a usual configuration, there is the gnrc_netdev2 thread which calls the gnrc_netdev2_ieee802154 _send function.

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2.c#L146

In there, the 802.15.4 header is prepared and the net device (netdev2) _send function is called

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev2/gnrc_netdev2_ieee802154.c#L141

This function is implemented by the device driver and usually results in writing the dara to the radio tx buffer as well as triggering the actual transmission.

https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L119

So far, for the moment.

Best Peter