• State Not Answered
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 2067 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301098
Options

IoT BLE DNS example using Ubuntu (on VM VirtualBox) as 6loWPAN router doesn't reply

hector77

Hi,

I am running the following example from the SDK for Thread v4.1.0: IOT/DNS and followed the SDK instructions to setup the BLE devices as well as an Ubuntu VM acting as the router.

The BLE device returns an error (<info> app: DNS Response for hostname: www.google.com, with 0 IPv6 addresses and status 0x0000C440).$

Ubuntu runs on Oracle VM VirtualBox, with the network adapter attached as "Bridged" in order to  effectively create a network interface

Please see the full log of the BLE device here (with log enabled):

<debug> dns6: >> dns6_query
<debug> dns6: << dns6_query
<debug> dns6: >> dns6_timeout_process
<debug> dns6: << dns6_timeout_process
<info> app: Got ICMP6 Application Handler Event on interface 0x0x20004EC8
<info> app: Source IPv6 Address:
FE80:0000:0000:0000:105B:ADFF:FE45:3B92
<info> app: Destination IPv6 Address:
2001:0DB8:0000:0000:0066:95FF:FEB5:E987
<info> app: Process result = 0x00000000
<info> app: Application in resolving state.
<info> app: Start button has been pushed.
<info> app: Got ICMP6 Application Handler Event on interface 0x0x20004EC8
<info> app: Source IPv6 Address:
2001:0DB8:0000:0000:0000:0000:0000:0001
<info> app: Destination IPv6 Address:
2001:0DB8:0000:0000:0066:95FF:FEB5:E987
<info> app: Process result = 0x00000000
<debug> dns6: >> dns6_timeout_process
<error> dns6: DNS server did not response on query for hostname www.google.com.
<info> app: DNS Response for hostname: www.google.com, with 0 IPv6 addresses and status 0x0000C440
<debug> dns6: << dns6_timeout_process
<info> app: Application in querying state.

The DNS server used is unchanged from the example code.

The ping's seem to work fine:
On Ubuntu, I can ping the DNS target from the command line:

ping6 www.google.com
PING www.google.com(zrh04s16-in-x04.1e100.net (2a00:1450:400a:808::2004)) 56 data bytes
64 bytes from zrh04s16-in-x04.1e100.net (2a00:1450:400a:808::2004): icmp_seq=1 ttl=57 time=10.2 ms
64 bytes from zrh04s16-in-x04.1e100.net (2a00:1450:400a:808::2004): icmp_seq=2 ttl=57 time=9.77 ms
64 bytes from zrh04s16-in-x04.1e100.net (2a00:1450:400a:808::2004): icmp_seq=3 ttl=57 time=8.97 ms

I can ping the BLE device with its local-link address:

ping6 -I bt0 fe80::66:95ff:feb5:e987
ping6: Warning: source address might be selected on device other than: bt0
PING fe80::66:95ff:feb5:e987(fe80::66:95ff:feb5:e987) from :: bt0: 56 data bytes
64 bytes from fe80::66:95ff:feb5:e987%bt0: icmp_seq=1 ttl=64 time=99.7 ms
64 bytes from fe80::66:95ff:feb5:e987%bt0: icmp_seq=2 ttl=64 time=134 ms
64 bytes from fe80::66:95ff:feb5:e987%bt0: icmp_seq=3 ttl=64 time=124 ms

I can ping the BLE device with its global address:

ping6 -I bt0 2001:db8::66:95ff:feb5:e987
PING 2001:db8::66:95ff:feb5:e987(2001:db8::66:95ff:feb5:e987) from 2001:db8::1 bt0: 56 data bytes
64 bytes from 2001:db8::66:95ff:feb5:e987: icmp_seq=1 ttl=64 time=164 ms
64 bytes from 2001:db8::66:95ff:feb5:e987: icmp_seq=2 ttl=64 time=139 ms
64 bytes from 2001:db8::66:95ff:feb5:e987: icmp_seq=3 ttl=64 time=173 ms

But it is unclear to me what is the expected behavior if I use the 2001:db8 prefix reserved for documentation and test ? Should the example work?

A then what is the exact procedure to use real case prefix, and how to get them ? If you could provide a specific example, that would help a lot.

I have tried other prefixes, or to extract the prefix from the IPv6 address of the ethernet interface (starts with 2a02:xxxx...) but no differences.

Many thanks for your help and suggestions.

Best regards, 

H

Parents
  • 0

    Hi,

    Note that this is an experimental example you are testing, that has been removed in later releases of the nRF5-SDKs. 

    Could you explain a bit about what kind of product you are making here?

    For a nRF52-series product that uses IPv6, I would recommend looking into Thread and Matter instead of IPv6 over BLE.

    If you are creating a new product, I recommend you to checkout the nRF Connect SDK instead of nRF5-SDK.

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/getting_started.html

    PS: If IPv6 over BLE is an requirement, then this sample here might be useful:  https://github.com/nrfconnect/sdk-zephyr/tree/main/samples/bluetooth/ipsp

    See also this statement regarding nRF5-SDK:

     nRF Connect SDK and nRF5 SDK statement 

  • 0 in reply to Sigurd

    Dear Sigurd, 

    Many thanks for the update. 

    I am trying to update an existing product running on an nRF 52832, and add some kind of IP connectivity in the simplest way possible (with a simple modification of the existing advertising packet we can initiate IPv6 over BLE, which is very nice). The idea is to upload data with TFTP, and get a clock sync with NTP for timestamping the data (CoAP also is very nice for possible future add-on).

    As you suggested, Thread would be ok, but I believe the SDK requires nRF52840 or other, not 52832. This is the main reason why we test IPv6 over BLE.
    https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_thread_zigbee_latest.html

    Q1. What would be the alternatives to achieve data upload and clock sync?

    In the meantime I have confirmed IPv6 support and prefix delegation with the ISP and we have run some more tests updating the global address configuration of the setup. But still, we cannot make it work yet.

    Q2. When you say the sample is experimental and now removed for the SDK, does this mean it doesn't work off-the-shelf with an unmodified DK52 board (+RPi as suggested in the documentation) ?

    Q3. Would you have a more detailed procedure on how to go for global address using the DK52 and IPSP sample, possibly some screen capture of what you get when you run it ? That would help a lot. From there we should be able to find our way ( I am not a network specialist ).

    Best regards, H

    Edit: this is as far a I can track the issue, with a tcpdump for bt0 where we can see all the ICMP packets (just in case that rings a bell or you see something obviously wrong in my setup).

    When I ping from the Raspberry (ie, border router) using a global address, the ping reaches the nRF node and I get this:
    root@raspberrypi:/etc# tcpdump -X -vv ip6 -i bt0
    tcpdump: listening on bt0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
    19:15:38.650485 IP6 (flowlabel 0x428bb, hlim 64, next-header ICMPv6 (58) payload length: 64) fd00:a::1 > fd00:a::66:95ff:feb5:e987: [icmp6 sum ok] ICMP6, echo request, id 44, seq 30
    0x0000: 6004 28bb 0040 3a40 fd00 000a 0000 0000 `.(..@:@........
    0x0010: 0000 0000 0000 0001 fd00 000a 0000 0000 ................
    0x0020: 0066 95ff feb5 e987 8000 5199 002c 001e .f........Q..,..
    0x0030: 4a94 c563 b0ec 0900 0809 0a0b 0c0d 0e0f J..c............
    0x0040: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
    0x0050: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!"#$%&'()*+,-./
    0x0060: 3031 3233 3435 3637 01234567

    When I ping from another host (on the same local net) using a global address, the ping is still visible at bt0, but does NOT reaches the nRF node:
    root@raspberrypi:/etc# tcpdump -X -vv ip6 -i bt0
    tcpdump: listening on bt0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
    19:20:28.247448 IP6 (flowlabel 0x6aad4, hlim 63, next-header ICMPv6 (58) payload length: 64) fd00:b::2 > fd00:a::66:95ff:feb5:e987: [icmp6 sum ok] ICMP6, echo request, id 49, seq 7
    0x0000: 6006 aad4 0040 3a3f fd00 000b 0000 0000 `....@:?........
    0x0010: 0000 0000 0000 0002 fd00 000a 0000 0000 ................
    0x0020: 0066 95ff feb5 e987 8000 85fc 0031 0007 .f...........1..
    0x0030: 6c95 c563 0000 0000 8cc8 0300 0000 0000 l..c............
    0x0040: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
    0x0050: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!"#$%&'()*+,-./
    0x0060: 3031 3233 3435 3637 01234567

    We can see the source address are different, but otherwise packets seems similar. In the second case however, it seems they are not forwarded/not reaching destination.

  • 0 in reply to hector77

    Hi,

    So it's working as expected using a Raspberry as the router, but it does not work with Ubuntu VM acting as the router ?

  • 0 in reply to Sigurd

    Dear Sigurd,

    Sorry I was not clear enough. Both Raspberry and VM work, the issue is between link-local addresses and non link-local.

    With a link-local address, packets go through bt0 BLE interface and reach the node. With a global address, I see packets on bt0 (see edit above), but they never reach the node.

  • 0 in reply to hector77

    Dear Sigurd, 

    I hope you are fine.

    In the last few tickets I sent, Nordic did reply consistently and very timely, which so valuable and apreciated. So here, I am just wondering what is the status of this ticket (now 24 days old I guess)?

    Just for my information, could you please just let me know if you intend to come back to us on this issue ? That would be great.
    Thanks again for all your kind support.

    Best, 

    H

Reply Children
No Data
Related
Terms of service