• State Not Answered
  • Replies 11 replies
  • Subscribers 88 subscribers
  • Views 2256 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 270747
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

unstable connection from IoT example: ipv6_icmp to RPI border router

data

 I use nRF52832 DK as the node and RPI as the border router.

I fowllowed the guide setup the border router and flash the example ipv6_icmp to the nRF52832 DK.

The connection can be established. The local-link address is right.But I can not find the global address.

And most important thing is that the connection can only last about a few seconds, then disconnected unexpectly.

Is there something wrong ?

mount -t debugfs none /sys/kernel/debug
echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable

echo "connect 00:E9:92:E1:xx:xx 1" > /sys/kernel/debug/bluetooth/6lowpan_control

/home/pi# ifconfig bt0
bt0: flags=4161<UP,RUNNING,MULTICAST> mtu 1280
inet6 fe80::dca6:32ff:fexx:xxxx prefixlen 64 scopeid 0x20<link>
unspec DC-A6-32-xx-xx-xx-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 361 (361.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

/home/pi# ping6 -I bt0 fe80::e9:92ff:fee1:xxxx
ping6: Warning: source address might be selected on device other than bt0.
PING fe80::e9:92ff:fee1:9871(fe80::e9:92ff:fee1:9871) from :: bt0: 56 data bytes
64 bytes from fe80::e9:92ff:fee1:9871%bt0: icmp_seq=1 ttl=64 time=62.2 ms
64 bytes from fe80::e9:92ff:fee1:9871%bt0: icmp_seq=2 ttl=64 time=84.9 ms
64 bytes from fe80::e9:92ff:fee1:9871%bt0: icmp_seq=3 ttl=64 time=107 ms
......
ping: sendmsg: \u6ca1\u6709\u90a3\u4e2a\u8bbe\u5907
ping: sendmsg: \u6ca1\u6709\u90a3\u4e2a\u8bbe\u5907
^C
--- fe80::e9:92ff:fee1:9871 ping statistics ---
15 packets transmitted, 10 received, 33.3333% packet loss, time 168ms
rtt min/avg/max/mdev = 54.804/78.305/106.797/16.196 ms

/home/pi# ifconfig bt0
bt0: error fetching interface information: Device not found

Parents Reply Children
  • 0 in reply to Håkon Alseth

    I'm using the nrf52 SDK 16.0, and I follow the instructions the index you provided. 

    I'd like to know why the bluetooth 6lowpan removed.

  • 0 in reply to data

    /var/log/syslog

    message below repeats everytime trying to connect:

    May 29 16:04:22 raspberrypi bluetoothd[5362]: No cache for 00:E9:92:E1:98:71
    May 29 16:04:24 raspberrypi avahi-daemon[393]: Joining mDNS multicast group on interface bt0.IPv6 with address fe80::dca6:32ff:fed1:1e2c.
    May 29 16:04:24 raspberrypi avahi-daemon[393]: New relevant interface bt0.IPv6 for mDNS.
    May 29 16:04:24 raspberrypi avahi-daemon[393]: Registering new address record for fe80::dca6:32ff:fed1:1e2c on bt0.*.
    May 29 16:04:24 raspberrypi kernel: [ 8085.977647] Bluetooth: hci0: link tx timeout
    May 29 16:04:24 raspberrypi kernel: [ 8086.415729] Bluetooth: hci0: link tx timeout
    May 29 16:04:25 raspberrypi kernel: [ 8086.819299] Bluetooth: hci0: link tx timeout
    May 29 16:04:25 raspberrypi ModemManager[392]: <info> Couldn't check support for device '/sys/devices/platform/soc': not supported by any plugin
    May 29 16:04:25 raspberrypi ntpd[551]: Listen normally on 36 bt0 [fe80::dca6:32ff:fed1:1e2c%22]:123
    May 29 16:04:25 raspberrypi ntpd[551]: new interface(s) found: waking up resolver
    May 29 16:05:02 raspberrypi avahi-daemon[393]: Interface bt0.IPv6 no longer relevant for mDNS.
    May 29 16:05:02 raspberrypi avahi-daemon[393]: Leaving mDNS multicast group on interface bt0.IPv6 with address fe80::dca6:32ff:fed1:1e2c.
    May 29 16:05:02 raspberrypi avahi-daemon[393]: Withdrawing address record for fe80::dca6:32ff:fed1:1e2c on bt0.
    May 29 16:05:04 raspberrypi ntpd[551]: Deleting interface #36 bt0, fe80::dca6:32ff:fed1:1e2c%22#123, interface stats: received=0, sent=0, dropped=0, active_time=39 secs

  • 0 in reply to data

    Hi,

     

    What does the firmware itself state? Does it show any uart output that might give an indication on what the disconnect reason is?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi,

    The firmware didn't use uart as output.But I checked the RTT LOG info.

    I found no error in the log. I only got this message when the connection breaks:

       <info>  app: Interface removed!

       <info>  app: Physical layer disconnected.

       <info>  app: Physical layer in connectable mode.

    I think the firmware runs well.The problem must happends in the RPI.

    But I'm not familar with this part of RPI.

    I hope I can get help from you guys.

    Tanks a lot.

    Sincerely regards, 

    mark baum

  • 0 in reply to data

    Hi,

     

    Is that the only log that is shown?

    Does other iot samples behave equally?

     

    Kind regards,

    Håkon

Related
Terms of service