nRF Mesh Reply Attack Problem

Hi,

I am developing a vendor specific Mesh Model, I have already integrated the mesh model sucessfully to my network and is able to send data from each node by multiple hops. I am facing some issues from the mesh model.

1. During data transmission if the device resets, reply attack happens and that data wont be received 

2. This is my config. I have done everything I can can to increase the throughput, please advise if there are any other way to increase speed to accommodate my payload size. My payload from one node is 240bytes.   

 

[12:21] Jeslin James
CONFIG_ADC=y
CONFIG_ADC_ASYNC=y
CONFIG_GPIO=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_PWM=y
CONFIG_LOG_PRINTK=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_PWM_LOG_LEVEL_DBG=y
CONFIG_NEWLIB_LIBC=y
CONFIG_ADC_NRFX_SAADC=y
CONFIG_NRFX_SAADC=y
CONFIG_LOG=y
CONFIG_PM=y
CONFIG_PM_DEVICE=y
 
#RTC lib enabling
CONFIG_I2C=y
 
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
 
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n
CONFIG_BT_BUF_ACL_RX_SIZE=498
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_L2CAP_TX_MTU=484
 
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_ACL_TX_SIZE=37
 
CONFIG_LOG_DEFAULT_LEVEL=3
 
CONFIG_FLASH=y
CONFIG_SPI=y
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_FLASH_PAGE_LAYOUT=y
 
CONFIG_NVS=y
CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_REBOOT=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
 
#Enable timer1
CONFIG_NRFX_TIMER1=y
 
CONFIG_W1=y
CONFIG_SENSOR_LOG_LEVEL_DBG=y
 
#Floating point support
CONFIG_CBPRINTF_FP_SUPPORT=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_CBPRINTF_COMPLETE=y
 
 
CONFIG_BT_DEVICE_NAME="VISENSE_IRMTR"
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_NVS_LOOKUP_CACHE=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS_NAME_CACHE=y
CONFIG_HWINFO=y
CONFIG_DK_LIBRARY=y
CONFIG_PM_SINGLE_IMAGE=y
CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE=0x8000
CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE=y
 
 
# Temperature sensor
CONFIG_SENSOR=y
CONFIG_TEMP_NRF5=y
 
# Bluetooth configuration
CONFIG_BT=y
CONFIG_BT_COMPANY_ID=0x1234
CONFIG_BT_L2CAP_TX_BUF_COUNT=8
CONFIG_BT_OBSERVER=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_SETTINGS=y
CONFIG_BT_EXT_ADV=y
# 5 sets are used by Bluetooth mesh, 1 is needed for the sample advs.
CONFIG_BT_EXT_ADV_MAX_ADV_SET=6
CONFIG_BT_MAX_CONN=3
CONFIG_BT_ID_MAX=2
 
# Disable unused Bluetooth features
CONFIG_BT_CTLR_DUP_FILTER_LEN=0
CONFIG_BT_CTLR_LE_ENC=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_CTLR_CHAN_SEL_2=n
# CONFIG_BT_CTLR_MIN_USED_CHAN=n
CONFIG_BT_CTLR_PRIVACY=n
 
# Bluetooth mesh configuration
CONFIG_BT_MESH=y
CONFIG_BT_MESH_RELAY=y
CONFIG_BT_MESH_FRIEND=y
CONFIG_BT_MESH_ADV_BUF_COUNT=13
CONFIG_BT_MESH_TX_SEG_MAX=22
CONFIG_BT_MESH_RX_SEG_MAX=22
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_PROXY_USE_DEVICE_NAME=y
CONFIG_BT_MESH_DK_PROV=y
CONFIG_BT_MESH_SUBNET_COUNT=2
CONFIG_BT_MESH_APP_KEY_COUNT=3
# CONFIG_BT_MESH_CRPL=10
CONFIG_BT_MESH_MSG_CACHE_SIZE=32
CONFIG_BT_MESH_CRPL=1000
 
 
CONFIG_BT_MESH_RELAY_RETRANSMIT_COUNT=2
CONFIG_BT_MESH_TX_SEG_MSG_COUNT=5
CONFIG_BT_MESH_RX_SEG_MSG_COUNT=6
CONFIG_BT_MESH_TX_SEG_RETRANS_COUNT=4
 
 
 
CONFIG_BT_MESH_MODEL_KEY_COUNT=1
CONFIG_BT_MESH_MODEL_GROUP_COUNT=1
CONFIG_BT_MESH_APP_KEY_COUNT=3
CONFIG_BT_MESH_SEG_BUFS=128
 
CONFIG_BT_MESH_ADV_EXT=y
 
 
 
#PMIC
CONFIG_NRF_FUEL_GAUGE=y
#CONFIG_SHELL=y
 

3. My most vexing issue is even with 0 hops sending 240 bytes payload in a single send, I am facing a delay of 2 seconds, The time taken to start the transmission from the callback of START and to reach the callback of END of the message i am getting a delay of 2 seconds. This is too long for my implementation, kindly advice on ways to reduce it.

Parents Reply Children
  • Hi,  

    Please let me know if are there any solution to this

  • Hi, 

    Sorry for the delay. It took time for your answers. 

    Regarding the first question: I can't seem to reproduce their problem using the supplied config file. Is this the config you use on both ends? I tried resetting both the sender and receiver (both using the config supplied) several times (including resetting after the message sending but before RPL was stored in settings), but RPL functionality worked as expected. If you use a different config or firmware on one of the sides, this would be interesting to know. As of now, I can't reproduce this issue with the information I have.

    My most vexing issue is even with 0 hops sending 240 bytes payload in a single send, I am facing a delay of 2 seconds

    The two seconds taken is expected with the default network transmit configuration.

    The default number of time each Network PDU is sent: 3, configured by CONFIG_BT_MESH_NETWORK_TRANSMIT_COUNT. Its default value is 2, meaning each segment is transmitted 3 times.

    The default interval between network PDUs (CONFIG_BT_MESH_NETWORK_TRANSMIT_INTERVAL) : 20 (ms)

    Time spent sending each Network PDU: 60ms + advertisement delays

    At the Lower Transport Layer, it will be broken into 20 Lower Transport PDUs (240/12=20, segment buffer is 12 bytes long)

    Time spent sending 20 PDUs: 60ms * 20 PDUs + advertisement delays == 1200ms + advertisement delays

    With the default configuration, around 1,5 or so seconds (with no packet loss) is expected. To decrease this time, the easiest is to lower the network transmit count or the network transmit interval, keeping in mind the tradeoffs (lower transmit count could make things less reliable, and lower interval could cause more collisions)

    Regards,
    Amanda H.

Related