search

cetic / 6lbr

A deployment-ready 6LoWPAN Border Router solution based on Contiki
github.com/cetic/6lbr/wiki
Other
337 stars 194 forks source link

6lbr strange behavior with latest cc26xx-web-demo #234

Closed vad32m closed 7 years ago

vad32m commented 7 years ago

About week ago I succeed with building my first 6lowPAN sensor network. The setup is following: 6lbr, running under Ubuntu VM with cc1310 slip-radio connected to it. Output from slip-radio is following: slip_output. And another node, running cc26xx-web-demo. Now it have following configuration: web_demo_after_reset It worked great, until I downloaded the latest version of Contiki and re-flashed node with cc26xx-web-demo. Unfortunately, I made no backup and I dont know, what commit that was. Flashed with the latest version my node doesnt seem to work: after connecting to the router I try to access web-page on my node, sometimes browser is able to load page, sometimes not, but anyway, after short data transmittion it hangs. Wireshark log from 6lbr interface (my node IP is aaaa::212:4b00:a27:b808): wireshark_web_demo_conf After that if I reboot router and slip radio, node wont appear in the 6lbr "sensors" page. Only if I will reboot that node, it will be able to connect to the router. Devices are configured to the same channel and PAN ID, BLE beacon disabled. 6LoPWAN context 0 is set to fd00:: Anyway strange behavior is noticed only with 6lbr, if I launch the same web-demo with rpl-border-router and tunslip6, my demo works OK. I modified UART driver, as suggested here, and enclosing my logs. Maybe someone can give me solution. Also I am able to connect my cc26xx-web-demo to the GDB and make some debugging, but I dont know what should I look for. WEBREMO_6lbr.txt WEBDEMO_RPL_ROUTER.txt 6lbr_logs.zip

vad32m commented 7 years ago

I examined the log and discovered following: RPL router substitutes destination address correctly, because from my node log I see following lines: 15.4-IN: 1 0012:4b00:0af6:0265 0012:4b00:0a27:b808 21 64 (85) packetbuf_set_len: len 63 Where 0012:4b00:0a27:b808 is my node's MAC address. In case with 6lbr and slip-radio I have following messages: 15.4-IN: 1 0012:4b00:0af6:0265 0000:0000:0000:0000 15 80 (95) packetbuf_set_len: len 95 which is later followed by 15.4-IN: 1 0012:4b00:0af6:0265 020a:0bff:ff0c:0d0e 21 84 (105) nullrdc: not for us Destination addres is wrong, it is not my nodes address, but MAC of my tap0 interface 6lbr_ifconfig_tap0 Can anyone give me any advice, maybe there is something wrong with configuration? UPD: posted some additional info to this thread

vad32m commented 7 years ago

Finally got my WSN working again, but its stability is pretty low. Now my setup is: 6lbr Version : 1.5.x (Contiki-contiki-merge-20160622-77-gdc08685), cc1310 slip-radio flashed with YiKai's firmware(Contiki-3.x-2928-g1ebceb8) from here this thread. As sensor node I have cc1310 launchpad flashed with web-demo(Contiki-3.x-3067-g406cd56). In project-conf file I disabled BLE beacon and added following line #define UIP_CONF_ROUTER 0. Now my router is able to correctly discover that node and I am able to access CoAP and Web-servers. 6lbr_ok. 6lbr log in this case is following: 6lbr.log.txt But if I will delete line #define UIP_CONF_ROUTER 0 (default value is 1 as I think), strange behavior will repeat. And 6lbr will not be able to resolve MAC address. 6lbr_unresolved 6lbr log in this case is following: 6lbr.log.failure.txt Are you guys interested in further investigation an may I help you somehow?

Mecabot commented 7 years ago

Hi @vad32m :

You can try return to the previous version with which you programmed the CC1310 with the next instructions:

git clone https://github.com/cetic/6lbr cd 6lbr git submodule update --init --recursive cd examples/6lbr git checkout develop-xxxxx #optional, if you plan to use a develop snapshot

  source: https://github.com/cetic/6lbr/wiki/Other-Linux-Software-Configuration

You should replace the xxxxx with the version that you want.

In this image the version is g6cdba10

image

If you have some problem you can try with the version ge3d5b74 , i am ussing that version and is very stable.

image

laurentderu commented 7 years ago

I believe there is something wrong with the NDP message handling in Contiki. By default, 6LBR sends NS messages to the nodes to resolve their MAC address, on the other hand rpl-border-router does not.

Could you try and set back again UIP_CONF_ROUTER to 1 and also define UIP_CONF_ND6_SEND_NA to 1 in your project-conf.h of your node ?

vad32m commented 7 years ago

@laurentderu I did tried what you suggested and it works OK. Also I made checkout to version g1ebceb8 and corresponding versions of cc26xx- and cc13xx-ware. The problem is ContikiMAC doesn't suit my application, so I would like to use faster nullrdc driver. If I re-flash my node to use nullrdc, my wsn still works good. But if I re-flash my slip-radio with the firmware compiled for nullrdc_noframer_driver, after a moment router will stop receiving answers from node: from 6lbr web page I can see it's MAC is properly resolved an from COAP server I can toggle LEDs on my node, but no answers will come. UPD: the most interesting thing, is that such strange behavior occurs when I use nullrdc_noframer driver for slip radio, if I use nullrdc driver instead everything works perfect.

laurentderu commented 7 years ago

You must use nullrdc_driver, the nullrdc_noframer_driver lacks several critical features like Acking and message duplication detection and so should not be used unless for very specific use cases.

vad32m commented 7 years ago

@laurentderu I was disorientated with following lines in slip-radio project-conf file: #undef NETSTACK_CONF_RDC /* #define NETSTACK_CONF_RDC nullrdc_noframer_driver */ #define NETSTACK_CONF_RDC contikimac_driver