Netdev2 - Events/Flags wich cause netdev2 to transmit

Neo · 31 August 2016 23:28

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

PeterKietzmann · 1 September 2016 07:06

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

github.com

RIOT-OS/RIOT/blob/master/sys/include/net/netopt.h#L91


      
          NETOPT_ADDRESS_LONG,
          /**
           * @brief   (uint16_t) get the default address length a network device expects
           */
          NETOPT_ADDR_LEN,
          /**
           * @brief   (uint16_t) address length to use for the link layer source address
           */
          NETOPT_SRC_LEN,
          /**
           * @brief   (uint16_t) network ID
           *
           * Examples for this include the PAN ID in IEEE 802.15.4 and netid in
           * LoRaWAN (uint32_t in this case)
           */
          NETOPT_NID,
          
          /**
           * @brief   (uint8_t) hop limit
           */
          NETOPT_HOP_LIMIT,

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.

github.com

RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L119


      
                                        (aes_block_t *)plain,
                                        nblocks);
          }
          
          /**
           * @brief   Perform ECB encryption
           *
           * @param[in]       dev         Abstract security device descriptor
           * @param[out]      cipher      Output cipher blocks
           * @param[in]       plain       Plain blocks
           * @param[in]       nblocks     Number of blocks
           */
          static void _at86rf2xx_ecb(const ieee802154_sec_dev_t *dev,
                                     uint8_t *cipher,
                                     const uint8_t *plain,
                                     uint8_t nblocks)
          {
              at86rf2xx_aes_ecb_encrypt((at86rf2xx_t *)dev->ctx,
                                        (aes_block_t *)cipher,
                                        NULL,
                                        (aes_block_t *)plain,

So far, for the moment.

Best Peter