LAUNCHXL-CC1310: contiki mqtt client stuck in "Connecting..."

Try to run wrapsix instead of IP64 on 6lbr to see if it works.

Hi Chen, thanks for reply.

I ran wrapsix on RaspPi with below settings:

pi@raspberrypi:~/wrapsix-0.2.1 $ sudo wrapsix wrapsix.conf
[Info] WrapSix 0.2.1 is starting
[Info] Using: interface eth0
[Info] prefix 64:ff9b::
[Info] MTU 1500
[Info] IPv4 address 192.168.0.111 <== Random unused IP in my LAN
[Info] host IPv4 address 192.168.1.7 <== RASPPI IPV4 address
[Info] host IPv6 address bbbb::101 <== 6lbr IP


But, still the mqtt connection is not established on CC1310 end node.

However, i see tcpdump dumping all the 1883 packets now on eth0 of RaspPi and en0 of my MAC but only in one direction.
Mqtt packets are received from my CC1310 end node on these interfaces but i dont see any response to them.

RASPBERRY PI TCPDUMP:
======================

pi@raspberrypi:~ $ sudo tcpdump -i eth0 port 1883
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:14:48.133688 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 0, win 128, options [mss 128], length 0
02:14:49.113129 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 0, win 128, options [mss 128], length 0
02:14:51.288495 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 0, win 128, options [mss 128], length 0
02:14:54.790768 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 0, win 128, options [mss 128], length 0
02:15:01.290629 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 0, win 128, options [mss 128], length 0
02:15:13.944840 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 0, win 128, options [mss 128], length 0
02:15:38.451768 IP6 fd00::212:4b00:13a4:636e.1027 > 64:ff9b::b8ac:7cbd.1883: Flags [R.], seq 0, ack 0, win 128, length 0
02:15:46.455616 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 100, win 128, options [mss 128], length 0
02:15:47.460627 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 100, win 128, options [mss 128], length 0
02:15:49.460756 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 100, win 128, options [mss 128], length 0
02:15:52.960742 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 100, win 128, options [mss 128], length 0
02:15:59.460732 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 100, win 128, options [mss 128], length 0
02:16:11.960688 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 100, win 128, options [mss 128], length 0
02:16:36.466657 IP6 fd00::212:4b00:13a4:636e.1029 > 64:ff9b::b8ac:7cbd.1883: Flags [R.], seq 100, ack 0, win 128, length 0
02:16:52.470404 IP6 fd00::212:4b00:13a4:636e.1030 > 64:ff9b::b8ac:7cbd.1883: Flags [S], seq 200, win 128, options [mss 128], length 0


MAC TCPDUMP :
===============


Ganis-MacBook-Pro:jjj ganikoduri$ sudo tcpdump -i en0 port 1883
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:44:54.795612 IP6 fd00::212:4b00:13a4:636e.exosee > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 0, win 128, options [mss 128], length 0
07:45:01.295498 IP6 fd00::212:4b00:13a4:636e.exosee > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 0, win 128, options [mss 128], length 0
07:45:13.949702 IP6 fd00::212:4b00:13a4:636e.exosee > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 0, win 128, options [mss 128], length 0
07:45:38.456639 IP6 fd00::212:4b00:13a4:636e.exosee > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [R.], seq 0, ack 0, win 128, length 0
07:45:46.460465 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 100, win 128, options [mss 128], length 0
07:45:47.465492 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 100, win 128, options [mss 128], length 0
07:45:49.465580 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 100, win 128, options [mss 128], length 0
07:45:52.965619 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 100, win 128, options [mss 128], length 0
07:45:59.465591 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 100, win 128, options [mss 128], length 0
07:46:11.965481 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 100, win 128, options [mss 128], length 0
07:46:36.471476 IP6 fd00::212:4b00:13a4:636e.solid-mux > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [R.], seq 100, ack 0, win 128, length 0
07:46:52.475239 IP6 fd00::212:4b00:13a4:636e.iad1 > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 200, win 128, options [mss 128], length 0
07:46:53.480224 IP6 fd00::212:4b00:13a4:636e.iad1 > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 200, win 128, options [mss 128], length 0
07:46:55.480624 IP6 fd00::212:4b00:13a4:636e.iad1 > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 200, win 128, options [mss 128], length 0
07:46:58.980541 IP6 fd00::212:4b00:13a4:636e.iad1 > 64:ff9b::b8ac:7cbd.ibm-mqisdp: Flags [S], seq 200, win 128, options [mss 128], length 0

I observe that i couldn't ping6 to 64:ff9b::b8ac:7cbd from my MAC or RaspberryPi as well.
However, i see the corresponding IPv4 address () is going fine.

Ganis-MacBook-Pro:~ ganikoduri$ ping 184.172.124.189
PING 184.172.124.189 (184.172.124.189): 56 data bytes
64 bytes from 184.172.124.189: icmp_seq=0 ttl=53 time=383.334 ms
64 bytes from 184.172.124.189: icmp_seq=1 ttl=53 time=304.242 ms
64 bytes from 184.172.124.189: icmp_seq=2 ttl=53 time=330.629 ms
64 bytes from 184.172.124.189: icmp_seq=3 ttl=53 time=345.046 ms
64 bytes from 184.172.124.189: icmp_seq=4 ttl=53 time=364.187 ms
64 bytes from 184.172.124.189: icmp_seq=5 ttl=53 time=283.909 ms
64 bytes from 184.172.124.189: icmp_seq=6 ttl=53 time=303.555 ms

Has it got anything to do with my router config now ?

Please help.

You should check if there is any firewall or anti-virus SW blocks MQTT traffics.

Hi Chen,

Can you please validate the tcpdump output that i mentioned in my previous post on RaspPi eth0 interface and on connected interface on my PC ? Is it expected to see IPv6 packets in the requests originating from end node on connected interface on PC ?

I will verify my router config and get back.

I don’t see tcpdump 1883 port output connection to IBM QuickStart.Do you use ibm QuickStart in your cc26xx-web-demo?

Yes chen, I am using the default broker ip in cc26xx-web-demo which is 64:ff9b::b8ac:7cbd and was supposed to be quickstart ibm broker ip.

I tried to get the IP of the quickstart.internetofthings.ibcloud.com

Ganis-MacBook-Pro:~ ganikoduri$ dig A quickstart.internetofthings.ibmcloud.com

; <<>> DiG 9.9.7-P3 <<>> A quickstart.internetofthings.ibmcloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33191
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;quickstart.internetofthings.ibmcloud.com. IN A

;; ANSWER SECTION:
quickstart.internetofthings.ibmcloud.com. 413 IN A 169.54.163.180

;; AUTHORITY SECTION:
internetofthings.ibmcloud.com. 413 IN NS ns1.softlayer.com.
internetofthings.ibmcloud.com. 413 IN NS ns2.softlayer.com.

;; Query time: 17 msec
;; SERVER: 125.22.47.125#53(125.22.47.125)
;; WHEN: Thu Mar 29 04:47:36 IST 2018
;; MSG SIZE rcvd: 131

==> I changed the broker ip in cc26xx-web-demo in the mqtt config page of the end node to 64:ff9b::a936:a3b4 now corresponding to 169.64.163.180 IPv4 address of the ibm broker.
Hope this is the IP that is expected to be used.

When you build cc26xx-web-demo example, IBM QuickStart IPv6 address is preprogrammed in it and you shouldn’t change it. Please use the default IPv6 address to test again.

Yes. I restored it back to the old quickstart ipv6 address that came with example code. behavior didn't change. connection still fails.

I dont find these packets being routed to wireless interface on my MAC as i dont find them in the tcpdump on the interface corresponding to my wiress LAN on my MAC.
They arrive on eth0 but they seem to be not getting forwarded outside of my MAC.

As i am using 6lbr in router mode, am i supposed to do some ipv4/ipv6 forwarding as mentioned in router mode section of the below wiki ?
github.com/.../6LBR-Interface-Configuration

It says as below:

IP Forwarding can be enabled by adding the following two lines in /etc/sysctl.conf:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding=1

But i didn't find /etc/sysctl.conf on my MAC to do this.
How to know if it is already enabled ? Is there any alternate command to do this ?

Thanks,
Gani

Its a partial success for me. I am able to make the CC1310 to publish to mosquitto on my RaspPi.

But for accessing the quickstart ibm server, i shall understand if it is mandatory to use smartbridge mode of 6lbr or any extra forwarding to be enabled on host side to get this done.

Thanks,
Gani

For some one's reference, i had to configure the bbbb address configured on my br0 interface on Raspberry Pi as MQTT broker IP for the end node.

Couldn't understand what you mean. Does it work now?

As i mentioned, i am able to use mosquitto broker on my Raspberry Pi for ipv6 communication from WSN nodes.
It seems to be some issue with wrapsix setting only to me as the ipv6 packets in WSN nodes are able to reach the eth interface on my MAC book in ipv6 format only.

Will work on it and update this link if that solves my issue.

what do you see now when you do tcpdump on port 1883? Do you check your firewall or antivirus SW blocks anything?

I think this issue might be caused by latest 6lbr source code. I suggest you to do "git checkout ff69ae4214407eeec4c71f87589ac4bc7d3a8a49" to get 6lbr version on 2016 Dec. 22th to test again.

Hi,

I have analyzed further with the sniffer in place.

I find that the 6lbr is stripping off the first 64 bit prefix of the destination IPv6 address when it puts on the slip-radio.

I tried to send ping packets to the aaaa ipv6 address of the end node that i find on 6lbr nodes page, but it removes aaaa from it.

Packets originating from MAC :

08:15:32.955005 IP6 bbbb::e87a:f98:144e:97b5 > aaaa::212:4b00:13a4:63ec: ICMP6, echo request, seq 0, length 16

08:15:33.955412 IP6 bbbb::e87a:f98:144e:97b5 > aaaa::212:4b00:13a4:63ec: ICMP6, echo request, seq 1, length 16

08:15:34.956674 IP6 bbbb::e87a:f98:144e:97b5 > aaaa::212:4b00:13a4:63ec: ICMP6, echo request, seq 2, length 16

but the destination ip address is shown as ::212:4b00:13a4:63ec in the packet capture through sniffer.

Global - 6LBR.pdf

Attached the configuration page of 6lbr for reference.

Can someone help if it is any 6lbr config issue that is cause this issue ? Because of this none of UDP or MQTT communication is working.

Do you run wrapsix on your 6lbr?

No Chen, wrapsix is not running on Raspberry Pi

Hi Chen,

Query #1:

My intention is to use mqtt broker on Raspberry Pi not the IBM broker

For test purpose, I have hardcoded broker Ip as bbbb::a:bff:fe0c:d0e. This is the bbbb address of br0 interface on Raspberry Pi.

Please suggest if this is fine ?

pi@raspberrypi:~ $ mosquitto -v

1524267743: mosquitto version 1.4.10 (build date Fri, 22 Dec 2017 08:19:25 +0000) starting

1524267743: Using default config.

1524267743: Opening ipv4 listen socket on port 1883.

1524267743: Opening ipv6 listen socket on port 1883.

Query #2:

Also, I am not able to access web link of the web-demo node.

I have the below settings in place for accessing aaaa WSN network IPs. But still the web link access doesn't work to WSN nodes

ifconfig en0 inet6 bbbb::101/64 add

sysctl -w net.inet6.ip6.accept_rtadv=1

route add -inet6 -prefixlen 64 aaaa:: bbbb::100

what am i missing here.

Query #3:

I see from packet capture that ONLY packet that gets exchanged with aaaa address between the 6lbr on Raspberry Pi and web demo end node is DIS packet.

Here, aaaa::212:4b00:13f2:4fbe corresponds to slip-radio node(6lbr) and aaaa::212:4b00:13a4:636e corresponds to the Web-demo node.

After this, communication is getting into problem, probably because of the missing 64 bit prefix in the IPv6 address fields of the packets. Any idea, what is this DIS packet is about ?

####

Please let me know if you need any more info on this.

####

Thanks,

Gani

Hi Edvard, Thanks a lot for the clarifications.

From this, it appears, web demo has some issue in responding to the mqtt broker. I will get a fresh version of 6lbr code and try with the web-demo bin generated from it.

Regarding the missing 64bit prefix, if it is omitted as part of UDP dissection, is the same expected for DIS packet also ?
We are seeing the full address only in case of DIS packet. Is this also expected ?

I will get back with results using fresh web demo application.

Thanks again !!!

And... Regarding my query on web link access of web demo node:Please find more info here

I am mentioning about the <web> link on the 6lbr sensor node page.
As part of Sensors tab display on 6lbr page, there is a web link provided against each of the WSN nodes in network.

The web link uses http connection to reach the WSN nodes allowing us to configure parameters like mqtt server etc.,
This page was not accessible for me.

Thanks,
Gani

The dissectors for RPL (for which DIS packets falls under) and UDP are different, and for RPL the address prefix is not omitted. I don't have a good answer to why one dissector omits it and one doesn't, however, that's how it is.

Ahh, I understand. Have you tried pinging the 6lbr webpage, i.e.

ping bbbb::100
# or maybe
ping6 bbbb::100

Yes 6lbr i can open when iwas not able to open web link for web demo node.


Here are some modifications that i tried:

In 6lbr.conf, while MODE was ROUTER, i was having BRIDGE param set to 1, i have it set it 0 now.
my conf file looks as below now:

pi@raspberrypi:/etc/6lbr $ cat 6lbr.conf
#This file contains a default configuration for Raspberry PI platform using
#a Telos SLIP Radio
#The full list of parameters and their meaning can be found in 6lbr.conf.example

MODE=ROUTER
#MODE=SMART-BRIDGE
#MODE=RPL-RELAY
#MODE=FULL-TRANSPARENT-BRIDGE
#MODE=NDP-ROUTER
#MODE=6LR
#MODE=RPL-ROOT

RAW_ETH=0
BRIDGE=0
DEV_TAP=tap0
#DEV_ETH=wlan0
DEV_ETH=eth0
RAW_ETH_FCS=0

DEV_RADIO=/dev/ttyACM0
#DEV_RADIO=/dev/serial0
BAUDRATE=115200

LOG_LEVEL=1 #INFO and above only


############
############

With this , i am able to open 6lbr page after I login to RaspPi GUI.
I can now even ping the fd00 address of the web demo end node( which i built after fresh checkout from contiki git).

But..... the ping response is very lossy..
I see 83% of packet loss with this.

pi@raspberrypi:/etc/6lbr $ ping6 fd00::212:4b00:13a4:63ec
PING fd00::212:4b00:13a4:63ec(fd00::212:4b00:13a4:63ec) 56 data bytes
From fd00::212:4b00:13a4:c534 icmp_seq=1 Destination unreachable: Beyond scope of source address
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=5 ttl=63 time=2973 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=6 ttl=63 time=7318 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=7 ttl=63 time=11269 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=8 ttl=63 time=16147 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=8 ttl=63 time=26410 ms (DUP!)
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=9 ttl=63 time=28028 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=10 ttl=63 time=69159 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=11 ttl=63 time=68361 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=12 ttl=63 time=67416 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=12 ttl=63 time=67509 ms (DUP!)
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=13 ttl=63 time=66564 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=14 ttl=63 time=74649 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=17 ttl=63 time=72731 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=19 ttl=63 time=70826 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=20 ttl=63 time=69879 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=21 ttl=63 time=70055 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=22 ttl=63 time=89760 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=24 ttl=63 time=87814 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=24 ttl=63 time=87908 ms (DUP!)
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=24 ttl=63 time=88002 ms (DUP!)
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=29 ttl=63 time=82790 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=34 ttl=63 time=77791 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=39 ttl=63 time=92195 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=43 ttl=63 time=90820 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=49 ttl=63 time=84674 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=54 ttl=63 time=80089 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=60 ttl=63 time=79731 ms
64 bytes from fd00::212:4b00:13a4:63ec: icmp_seq=66 ttl=63 time=79374 ms

--- fd00::212:4b00:13a4:63ec ping statistics ---
146 packets transmitted, 24 received, +4 duplicates, +1 errors, 83% packet loss, time 150429ms
rtt min/avg/max/mdev = 2973.887/64651.986/92195.599/27184.739 ms, pipe 89
pi@raspberrypi:/etc/6lbr $

#################################
tcpdump on tap0 interface is below:
#################################

02:20:57.551641 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 21, length 64
02:20:58.059003 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 89, length 64
02:20:59.096354 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 90, length 64
02:21:00.136366 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 91, length 64
02:21:01.176384 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 92, length 64
02:21:02.216371 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 93, length 64
02:21:03.256358 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 94, length 64
02:21:04.296379 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 95, length 64
02:21:05.336351 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 96, length 64
02:21:06.376378 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 97, length 64
02:21:07.416369 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 98, length 64
02:21:08.456357 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 99, length 64
02:21:09.496361 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 100, length 64
02:21:10.536375 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 101, length 64
02:21:11.586367 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 102, length 64
02:21:12.616374 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 103, length 64
02:21:13.656348 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 104, length 64
02:21:14.696360 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 105, length 64
02:21:15.736409 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 106, length 64
02:21:16.776373 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 107, length 64
02:21:17.816378 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 108, length 64
02:21:18.296300 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 22, length 64
02:21:18.390717 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 24, length 64
02:21:18.485192 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 24, length 64
02:21:18.578592 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 24, length 64
02:21:18.606931 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 29, length 64
02:21:18.767936 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 34, length 64
02:21:18.815544 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 109, length 64
02:21:19.816560 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 110, length 64
02:21:20.856376 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 111, length 64
02:21:21.896367 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 112, length 64
02:21:22.936359 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 113, length 64
02:21:23.976331 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 114, length 64
02:21:25.016390 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 115, length 64
02:21:26.056358 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 116, length 64
02:21:27.096363 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 117, length 64
02:21:28.136364 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 118, length 64
02:21:29.176355 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 119, length 64
02:21:30.216386 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 120, length 64
02:21:31.256379 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 121, length 64
02:21:32.296395 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 122, length 64
02:21:33.336380 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 123, length 64
02:21:34.376375 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 124, length 64
02:21:35.416380 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 125, length 64
02:21:36.456390 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 126, length 64
02:21:37.496408 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 127, length 64
02:21:38.411869 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 39, length 64
02:21:38.495535 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 128, length 64
02:21:39.496607 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 129, length 64
02:21:40.536413 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 130, length 64
02:21:41.196380 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 43, length 64
02:21:41.290985 IP6 fd00::212:4b00:13a4:63ec > bbbb::a:bff:fe0c:d0e: ICMP6, echo reply, seq 49, length 64
02:21:41.535824 IP6 bbbb::a:bff:fe0c:d0e > fd00::212:4b00:13a4:63ec: ICMP6, echo request, seq 131, length 64


The nodes(slip and web demo node) are next to each other.
From tcpdump on tap0 interface, It is reaching 6lbr node.

What is the better way to debug where these packets are dropped ?
can packets get dropped on web demo node side ?

Thanks,
Gani

Wondeful !!!
Actually, cc26xx-web-demo was using nullrdc_driver while slip-radio is using contikimac_driver as RDC.

After chaning RDC on cc26xxx-web-demo side to contikimac_driver, packet loss is resolved.
Probably, this mismatch was causing packet loss.
I was seeing issue data traffic only because of this mismatch, RPL traffic was not impacted.
I was able to see the sensor node getting discovered.

However, Now, after this change, I can see mqtt connection and web link to web-demo node is perfectly working.

Thanks a lot to both of you YiKai Chen & Severin Suveren