rdeterre commented 8 years ago

Please excuse me if this has already been answered. I've seen many similar posts but could not figure out the complete solution to my problem.

My setup is a Beaglebone Black edge router connected via USB to a CC1310 Launchpad running the slip-radio example from Contiki's master branch. The nodes are CC1310 Launchpads.

Nodes running cc26xx-web-demo using Contiki's 8b3d220 commit with TARGET=srf06-cc26xx BOARD=srf06/cc13xx set can be reached from my desktop computer, both using ping6 and through HTTP. On the other hand, if I compile and run the code sample on the nodes with Contiki's master branch (commit 01a533f), I cannot reach them, irrespective of using BOARD=srf06/cc13xx or BOARD=launchpad/cc1310.

I had read about the 8b3d220 commit from issue #1594. As per the comments in this ticket, I tried the following changes without success:

Set RF_BLE_CONF_ENABLED to 0
Add #define NETSTACK_CONF_RDC nullrdc_driver in the web demo's project-conf.h
Change the 6lbr prefix to 00fd, fd00 and fd01.

The way I changed the prefix is by going to 6lbr's web interface and replacing aaaa with the new prefix in the Prefix, 6LoPWAN context 0 and Manual address fields. I am worried that I am missing something here because this does not work even with the web demo examples compiled from the 8b3d220 commit. Is there something else I should do to be able to change the prefix?

Thanks

g-oikonomou commented 8 years ago

Please have a look at #1744 and try with #define CC2650_FAST_RADIO_STARTUP 0. Let us know what happens.

rdeterre commented 8 years ago

I re-compiled and flashed the web demo example with #define CC2650_FAST_RADIO_STARTUP 0 added to project-conf.h, but unfortunately it does not work. I had the aaaa prefix configured.

g-oikonomou commented 8 years ago

Any chance you can try without 6lbr but with a standard rpl-border-router under the ipv6 examples dir? Instructions how to build this one for cc26xx/cc13xx in the platform readme. Just need to get the 6lowpan prefix / context issue out of the picture

rdeterre commented 8 years ago

Sure, I'll try with the other border router as soon as possible. Thanks for your fast answers :)

rdeterre commented 8 years ago

Apologies, I haven't been able to get the rpl-border-router to work. I don't see any communication coming from the CC1310 nodes, irrespective of whether they have the 8b3d220 code of the web demo compiled or the new one. This is clearly a problem on my end, here is what I've done:

I commented the UIP_CONF_BUFFER_SIZE and UIP_CONF_RECEIVE_WINDOW as asked for in the platform readme
I compiled rpl-border-router with make TARGET=srf06-cc26xx BOARD=launchpad/cc1310 then flashed it on a CC1310 (with uniflash)
I then changed the rpl-border-router Makefile to add -s /dev/ttyACM0 -v5 in the tunslip invocation of the connect-router target. This is because the CC1310 enumerates as /dev/ttyACM{0|1} on my system, and I thought that getting a lot of debugging information would be good.
I then run make TARGET=srf06-cc26xx BOARD=launchpad/cc1310 connect-router and got the following output:

********SLIP started on ``/dev/ttyACM0''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` mtu 1500 up
ifconfig tun0 add fd00::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.2.99  netmask 255.255.255.255  destination 192.168.2.99
        inet6 fd00::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Packet from TUN of length 48 - write SLIP
0000 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 85 00 7d 36 00 00 00 00
Packet from TUN of length 48 - write SLIP
0000 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 85 00 7d 36 00 00 00 00
Packet from TUN of length 48 - write SLIP
0000 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 85 00 7d 36 00 00 00 00

Should I see something different?

Thanks

g-oikonomou commented 8 years ago

I usually run tunslip with -v2. I would expect to see the border router printing out its own address there. Try restarting the Launchpand while tunslip is running and you should see its startup debug messages.

rdeterre commented 8 years ago

Thanks for the information. I realized that my channel setting was wrong. After fixing this, I was able to see the node in the border router's web interface. I was not able to ping it though. Here is the output of the tunslip6 program:

[rdeterre@pomstation rpl-border-router]$ make TARGET=srf06-cc26xx BOARD=launchpad/cc1310 connect-router
sudo ../../../tools/tunslip6 -s /dev/ttyACM0 -v2 fd00::1/64
[sudo] password for rdeterre: 
********SLIP started on ``/dev/ttyACM0''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` mtu 1500 up
ifconfig tun0 add fd00::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.2.99  netmask 255.255.255.255  destination 192.168.2.99
        inet6 fd00::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

*** Address:fd00::1 => fd00:0000:0000:0000
Got configuration message of type P
Setting prefix fd00::
Server IPv6 addresses:
 fd00::212:4b00:a27:f0f1
 fe80::212:4b00:a27:f0f1
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:e9ce
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:e9ce
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:e9ce

And http://[fd00::212:4b00:a27:f0f1]/ displays:

Neighbors

fe80::212:4b00:a27:e9ce

Routes

fd00::212:4b00:a27:e9ce/128 (via fe80::212:4b00:a27:e9ce) 1790s

But pinging fe80::212:4b00:a27:e9ce does not work, as well as fd00::212:4b00:a27:e9ce

g-oikonomou commented 8 years ago

You'll never be able to ping fe80::<anything> when it's more than one hop away (which in your case it is). I can't see anything wrong with the tunslip output.

What happens if you change both BR and mesh node to use NullRDC instead?

g-oikonomou commented 8 years ago

Also, the version that you report as working is way too old and doesn't have LP/CC1310 support. What hardware were you using to test that version?

Can you test with something more recent? Something like 0313a42 perhaps?

rdeterre commented 8 years ago

I tried to define NETSTACK_CONF_RDC to nullrdc_driver in contiki-conf.h and recompile both the border router and the web demo node, but now I cannot access the border router's web interface. The output of tunslip is pasted below. This was done with commit 01a533f though, which is not the latest on master at all now it seems. I'll update my repo and test again ASAP.

About the more ancient version that I used, I was compiling the code with BOARD=srf06/cc13xx. I tried that and BOARD=launchpad/cc1310 on master and none worked. I'll try 0313a42 along with the latest master and will come back with results.

(cd ../../../tools && make tunslip6)
make[1]: Entering directory '/home/rdeterre/iot-hangar/cc1310-firmware/contiki/tools'
cc     tunslip6.c tools-utils.c   -o tunslip6
tunslip6.c: In function ‘stamptime’:
tunslip6.c:134:3: warning: implicit declaration of function ‘gettimeofday’ [-Wimplicit-function-declaration]
   gettimeofday(&tv, NULL) ;
   ^
make[1]: Leaving directory '/home/rdeterre/iot-hangar/cc1310-firmware/contiki/tools'
sudo ../../../tools/tunslip6 -s /dev/ttyACM0 -v2 fd00::1/64
[sudo] password for rdeterre: 
********SLIP started on ``/dev/ttyACM0''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` mtu 1500 up
ifconfig tun0 add fd00::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.2.99  netmask 255.255.255.255  destination 192.168.2.99
        inet6 fd00::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

*** Address:fd00::1 => fd00:0000:0000:0000
Got configuration message of type P
Setting prefix fd00::
Server IPv6 addresses:
 fd00::212:4b00:a27:a2d2
 fe80::212:4b00:a27:a2d2
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:e9ce
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:e9ce
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:e9ce
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d
slip-bridge: Destination off-link but no route src=fd00::1 dst=fd00::212:4b00:a27:a2d

rdeterre commented 8 years ago

Hi again. I tried to run the test from c9deeb4 today with nullrdc and I could access the web interface of the border router, saw the mote there but could not ping it.

On the other hand, 0313a42 works. I can ping and access the web interface of the mote using it.

g-oikonomou commented 8 years ago

@rdeterre Have you tried switching to a different channel?

g-oikonomou commented 8 years ago

Nope, it's not the channel. This appears to have been caused by #1684, I am suspecting ContikiMAC timings.

This is a bug. Thanks for reporting.

g-oikonomou commented 8 years ago

Please try with #1783, let me know what happens. Cheers.

rdeterre commented 8 years ago

Hi, thanks for the update. I just tried the bugfix/cc13xx/contikimac-timings branch from your repo and it did not seem to work. I cannot ping the motes.

g-oikonomou commented 8 years ago

Can you confirm that:

ee0b02c works
0313a42 does not

Please also let me know what happens with 5fe95fc , 66a2ecb , f1c37b3 if you have time.

rdeterre commented 8 years ago

Hi. I actually do not have the devices any more at this time. I will get more CC1310s, but it will take about two weeks. Sorry about that.

arurke commented 8 years ago

I'll just add my experience: I tested the new ccxxxxwares branch #1756 (which includes #1684), and I did not see any issues (this was without #1783). My setup was a BBB with cc1310em SLIP + 3 devices including a cc1310 launchpad - using ContikiMAC. The devices are in RPL leaf mode and receive one UDP frame at boot, and then transmit to the sink every sec. Upstream I am certain I had no major issues, while downstream I did not notice anything (although I did not pay close attention). Are there some special conditions needed for this issue to appear? (downstream only? nullrdc? node-to-node?)

g-oikonomou commented 8 years ago

Can you have a quick look at the downstream? ping for example.

arurke commented 8 years ago

tl;dr: #1783 fixes this (or at least a similar issue I observe)

I tested using COAP GET requests, and from application everything looked fine. However I pulled up the sniffer and indeed there was something wrong. The request-frame from GW is received correctly at the node yet it seems the GW does not receive the ACK, because I see the GW keeps retransmitting. In between all these retransmissions, the node replies to the COAP GET and strangely GW actually receives it, ACKs it, and continues retransmitting the request - hence it all looks fine at application layer.

Interestingly, the issue does not appear if I use an older node in combination with a post #1684 SLIP, so I thought the fix would only be needed at the node side, but no:

1756 SLIP, pre #1684 node: OK

1756 SLIP, #1756 node: Not OK

1756 SLIP, #1756 + #1783 node: Not OK

1756 + #1783 SLIP, #1756 + #1783 node: OK

g-oikonomou commented 8 years ago

Andreas thanks, that's very useful. I can see why #1783 is required on both ends.

arurke commented 8 years ago

Hehe now that I inspect it, I agree :+1:

rdeterre commented 8 years ago

Hi. It took longer that expected to have CC1310 launchpads again, but I've now been able to run the rpl-border-router using #1783 and it all works here. Thanks a lot!

contiki-os / contiki

Cannot ping launchpad CC1310 nodes with latest Contiki #1747

1756 SLIP, pre #1684 node: OK

1756 SLIP, #1756 node: Not OK

1756 SLIP, #1756 + #1783 node: Not OK

1756 + #1783 SLIP, #1756 + #1783 node: OK