Cannot open web page on CC2650 cc26xx-web-demo from 6lbr

[chenek]

I git latest Contiki and build cc26xx-web-demo for my CC2650STK. The following is the UART output

Starting Contiki-3.x-2278-g8f06451 With DriverLib v0.44336 TI CC2650 SensorTag Net: sicslowpan MAC: CSMA RDC: ContikiMAC, Channel Check Interval: 16 ticks RF: Channel 25 CC26XX Web Demo Process CC26XX Web Server CC26XX CoAP Server 6LBR Client Process CC26XX MQTT Client Process CC26XX Net UART Process Could not open flash to load config

I also git latest 6lbr and join cc2650STK to 6lbr. I can see CC2650STK list on 6lbr sensor list.

However, I cannot open the web page when I access it. What would be the problem?

[pdNor]

I have the same problem. git checkout 8b3d220 solved it for me.

[alignan]

The linked commit seems unrelated to the issue, are you sure that's the right commit? In any case if @chenek could test this and works, would you mind comparing what commit are you using? even better would be to use git bisect

[g-oikonomou]

Have you checked the discussion in #1573?

[pdNor]

Don't know anything about the commit really, just found the solution on the TI forum and it worked.

[chenek]

@g-oikonomou I had tried #1573 but it still doesn't work.

[g-oikonomou]

Does everything else work? I mean, is it just the web that's broken or is everything else broken too?

[chenek]

@g-oikonomou COAP doesn't work too.

[chenek]

According to sakitten from TI e2e fourm, the following git version would work cc26xx-web-demo from Contiki git checkout 8b3d220 with 6lbr git checkout 3715b49

[g-oikonomou]

@laurentderu any ideas?

[chenek]

@g-oikonomou Finally, I find out the problem is caused by setting "#define RF_BLE_CONF_ENABLED 1". After I revise it to "#define RF_BLE_CONF_ENABLED 0", it works again. Do you have any idea why it doesn't work with BLE beacon enable?

[g-oikonomou]

This is useful input, thanks.

The demo should work fine with BLE enabled and I have tested it successfully in the past. This needs looked into.

[g-oikonomou]

Hello people

I just updated my setup to contiki-os/contiki@fd15934 and cetic/6lbr@fc76af7480fc4ff82d48446a7623a2d4edad0603

I am using 6lbr in router mode on a BBB, with a CC2531 USB stick as slip-radio. I programmed a CC2650 tag with the web demo, enabled BLE advertisements over the CoAP interface and opened the tag's web page: Things worked just fine. I then configured the tag to publish MQTT to my local mosquitto broker, using a random ORG ID and auth token. Again, no problems.

I am powering the tag from a SmartRF.

On the 6lbr side I had to set "Prefix" and "6LoPWAN context 0" both to fd00:: to get 6lowpan compression to play nicely. I confirmed with wireshark that, where applicable, datagrams are flying around with stateful, compressed v6 addresses using the correct context.

I'm using firefox on OS X for what it's worth.

[chenek]

Finally, I get some time to test this again with latest Contiki and 6lbr by myself, it works now. Thank you!

[cnalley]

Could someone please provide some additional information on the solution? I'm having the same issue as the OP testing the web demo with two cc2650 launchpads. One configured as a slip radio and the other flashed with the web demo. I've seen several post that say set the prefix and context to fd00:: and another post said fd01::. I guess the TI tutorials are outdated. Is there any current documentation on what the default configuration should be?

[chenek]

You should set it to FD00.

[cnalley]

Thanks for the reply. After setting 6LoPWAN context 0 = fd00:: I see that CoAP is working now. Progress! but the nodes web page instead of just giving an immediate error message now just says connecting... forever in Firefox. For anyone troubleshooting a similar problem my prefix is still set to aaaa::. If I set the prefix to fd00:: as well nothing works. I've found a lot of similar post when looking at 6lbr routing issues from searches like "6lbr can't ping node" and will update if I find a solution.

[chenek]

Try to add "define NETSTACK_CONF_RDC nullrdc_driver" in project-conf.h of cc26xx-web-demo and test again.

[cnalley]

Added the definition and re-compiled and still no luck. It definitely feels like a routing issue so I'm going to get wireshark involved and see what's happening. I'll report back with what I find. I'm going to see if MQTT is working as well.

[cnalley]

More progress! There is still some packet loss issues but HTTP is working now. I think the problem was that I missed a note under link that said to remove the defines that limit the size of the uIP buffer. I re-flashed my CC2650 Launchpad as a slip radio with those lines removed and also installed 6lbr with the specific checkout mentioned above and that seemed to resolve the issue with the webpage. I'm not sure if the 6lbr version really made a difference though. My prefix is still set to aaaa:: and context is fd00::. I'm still having some packet loss issues and the down PRR percentage falls over time still as mentioned above. I think I may need to isolate everything on its on small dedicated network for further testing. I may also need to look deeper into the configuration changes mentioned here for the Raspberry Pi.

[shosant]

Are you able to get the data sensordata in the quick start page?

[cnalley]

I have not been able to get MQTT working yet.

[cnalley]

After getting Wireshark involved I now have a lot more information and symptoms that I find interesting:

1. With the prefix and context both set to fd00:: I can ping and access nodes via HTTP and CoAP from a windows machine. I assume this is because windows accepts RAs by default. If I activate the reception of RAs or set manual routes as described here on a linux machine I still can't ping or access nodes from that Linux machine.
2. With the prefix set to aaaa:: and context set to fd00:: I can ping and access nodes from Windows and Linux machines after configuring the Linux machines to accept RAs.
3. In either case I see a lot of TCP re-transmission and TCP duplicate acknowledgements in Wireshark.
4. When the prefix is set a aaaa:: and a node is directed to publish to a local Mosquitto MQTT broker I see a [PSH, ACK] and an [ACK] back and forth between source and destination but then I see a long series of TCP Dup ACKs. I'm subscribing to all topics on the broker end and receive nothing.
5. Down PPR still slowly descends to zero.

Do any of these symptoms sound indicative of the possible problem to anyone? I've tried switching back and forth between using a CC2531 slip radio and a CC2650 with no change and using several different older Contiki and 6lbr commits (including contiki fd15934 and 6lbr at fc76af7). The only thing I can think of that is different in my setup from those tested working by others is a Raspberry Pi used as an edge router instead of a BBB.

[cnalley]

I can now confirm that MQTT is working with a local MQTT broker. I believe it might have been this note below in the TI tutorial that I went back to that helped or waiting a long time (more on that to follow).

"Note! The RAW_ETH_FCS=0/1 has been found to be system dependent. Suggest to try with 0 first, if that is not working and you see CRC errors on the eth side, please try RAW_ETH_FCS=1. We have seen that some people are having issues getting the connection to IBM to work using wrong RAW_ETH_FCS setting. "

Alternatively it might have been just waiting a long time. My 6lbr statistics don't look good and Wireshark shows a repeated stream of Dup ACKs which make it seem like the node is very slow to respond. I'll paste my 6lbr statistics below. Down PRR at the time this was copied was 1.8%.

IP Received packets : 2902 Sent packets : 1337 forwarded packets : 964 Dropped packets : 1496 Wrong IP version or header length : 0 Dropped IP fragments : 0 Checksum errors : 0 Unsupported protocol : 0

ICMP Received packets : 239 Sent packets : 154 Dropped packets : 8 Unsupported type : 8 Checksum errors : 0

TCP Received packets : 153 Sent packets : 132 Dropped packets : 0 Checksum errors : 0 Ack errors : 0 Received RST : 0 retransmitted segments : 0 Dropped SYNs : 0 SYNs for closed ports : 0

UDP Received packets : 53 Sent packets : 53 Dropped packets : 0 Checksum errors : 0

NDP Received packets : 47 Sent packets : 124 Dropped packets : 0

RPL Memory overflow : 0 Local repairs : 0 Global repairs : 0 Invalid packets : 0 DIO timer resets : 8 Parent switch : 0 Forward errors : 0 Loop errors : 0 Loop warnings : 0 Root repairs : 0

CSMA Allocated packets : 0 Allocated neighbors : 0 Packet overflow : 0 Neighbor overflow : 0

Send packets : 748 Received packets : 788 Not acked packets : 15 Collisions : 1 Retransmissions : 15 Dropped packets : 1 Deferred packets : 0

RDC Callback count : 0 Ack timeout : 0 Parse error : 0

SLIP Messages sent : 752 Messages received : 1540 Bytes sent : 72882 Bytes received : 80207

[shosant]

Hi could you pls let me know if there is any tutorial on how to set up local mqtt server. I am unable to connect to the ibm quick start and would like to test it with other option.

I am able to ping the node from my winodws pc, but not from my bbb. COAP is working , but unable to get the data on ibm quick start. I have been using wrapsix NAT 64.

[cnalley]

To test that MQTT is working install Mosquitto MQTT broker on a local Linux machine → sudo apt-get install mosquitto mosquitto-clients will install the broker and client. To subscribe to all topics → mosquitto_sub -h localhost -v -t “#”. Point the node to the brokers IPv6 address (i.e. bbbb:: ... ) by accessing the MQTT config page (web page) on the node. Doing a tcpdump on port 1883 → tcpdump -i eth0 -v -X port 1883 is helpful in seeing that there is activity at the broker. Here is a link to a Mosquitto tutorial for more info. I think there is a native windows build for Mosquitto as well but I haven't tried it https://mosquitto.org/download/.

[shosant]

hi, thank you very much . I have installed mosquitto on my windows pc. It is up and running. The broker ip if is 192.168.1.3, then is it correct to enter 0064:ff9b:0000:0000:0000:0000:c0a8:0103 on the mqtt config page of the node on broker ip field? The type, Org id are default and auth token I havent entered any. Is this correct setting?

[cnalley]

I didn't have to make any changes to the org id or auth token. The address I used was the IPv6 address of the broker (not a converted IPv4 address) the bbbb::XXXX:XXXX... etc address. I found the address with ifconfig and then to double check it I used ping6 and watched over Wireshark (using a CC2531 as a sniffer) to confirm the IP of the broker. I would highly recommend the sniffer for troubleshooting. You might also try with a Linux machine. I haven't tried the Windows version of Mosquitto but I can think of a few things that might cause some additional issues like Windows firewall etc.

[g-oikonomou]

I am testing with latest master + PR #1779 (which I will merge when travis passes).

I am running a recent-ish version of 6lbr (Version : 1.4.0 (Contiki-6lbr-1.4.0)) on BBB, with a CC2531 USB dongle slip-radio, using prefix fd00::/64 and 6LoPWAN Context 0 fd00::.

Web demo works perfectly fine on SmartRF06+CC2650EM. I am running mosquitto on my OS X, device connected and publishing just fine. I can now also access the device from my mac, web pages and CoAP all work and the board is advertising itself over BLE. I am not seeing any problems whatsoever.

I am closing this.

[shosant]

@birdmanhoo thanks a lot! I was successfully able to get it with local MQTT.