This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC1350: How to get Ipv6 address of IBM Watson's https://xxxxxx.internetofthings.ibmcloud.com ?

Expert 1600 points
Part Number: LAUNCHXL-CC1350


I'm following: https://sunmaysky.blogspot.com/2018/04/how-to-connect-contiki-ng-cc26xx-web.html?showComment=1563152347588#c8522647133840033562

How to get the broker IPv6 address given that my IBM https://65n4d9.internetofthings.ibmcloud.com/ ?

When I ping I get:

ping 65n4d9.messaging.internetofthings.ibmcloud.com

Pinging us.messaging.internetofthings.ibmcloud.com [169.48.234.212] with 32 bytes of data:
Reply from 169.48.234.212: bytes=32 time=67ms TTL=54
Reply from 169.48.234.212: bytes=32 time=67ms TTL=54
Reply from 169.48.234.212: bytes=32 time=67ms TTL=54

If my ipv4 address is 169.48.234.212, how to change it to ipv6 to write it in cc26xx-web-demo MQTT configuration page?

  • The ipv6 address of 169.48.234.212 is mapped to 0064::ff9b::0000::0000::0000::0000::a930::ead4

  • Thanks YK, 

    The node still cannot connect, please check the following Debug Log of the MQTT process:

  • I suggest you to do more printf in MQTT connection to know exactly what happens.

  • Well, I suspect the Ipv6 address or the ibm setup more than the code, the code works fine for MQTT on Raspberry Pi.

    - Whenever I ping ping 65n4d9.messaging.internetofthings.ibmcloud.com I get a different ipv4 address. Why is that happening?

    - Why "predicted compliance" on the IBM page show unknown instead of Pass or Fail?

    - is it normal to get org id as "65n4d9" instead of "uc6bmi" ?

  • I think it’s normal to get org id as "65n4d9" instead of "uc6bmi".  “What do you mean “Whenever I ping ping 65n4d9.messaging.internetofthings.ibmcloud.com I get a different ipv4 address”? I had suggested you to do more printf in MQTT connection. Do you try it and get more information about connection issue?

  • Here is the ping results of today: 

    C:\Users\ahmed>ping 65n4d9.messaging.internetofthings.ibmcloud.com

    Pinging us.messaging.internetofthings.ibmcloud.com [169.46.7.60] with 32 bytes of data:
    Reply from 169.46.7.60: bytes=32 time=68ms TTL=54
    Reply from 169.46.7.60: bytes=32 time=74ms TTL=54
    Reply from 169.46.7.60: bytes=32 time=64ms TTL=54
    Reply from 169.46.7.60: bytes=32 time=66ms TTL=54

    Ping statistics for 169.46.7.60:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 64ms, Maximum = 74ms, Average = 68ms

    which is different from what I got a couple of days ago when I posted this problem:

    ping 65n4d9.messaging.internetofthings.ibmcloud.com

    Pinging us.messaging.internetofthings.ibmcloud.com [169.48.234.212] with 32 bytes of data:
    Reply from 169.48.234.212: bytes=32 time=67ms TTL=54
    Reply from 169.48.234.212: bytes=32 time=67ms TTL=54
    Reply from 169.48.234.212: bytes=32 time=67ms TTL=54

    10 minutes later...

    ping 65n4d9.messaging.internetofthings.ibmcloud.com

    Pinging us.messaging.internetofthings.ibmcloud.com [169.62.202.130] with 32 bytes of data:
    Reply from 169.62.202.130: bytes=32 time=67ms TTL=54
    Reply from 169.62.202.130: bytes=32 time=64ms TTL=54
    Reply from 169.62.202.130: bytes=32 time=68ms TTL=54
    Reply from 169.62.202.130: bytes=32 time=72ms TTL=54

    ------------------------------------------------------

    If the ip address is changing, how will the cc26xx-web-demo process follow it?

    ------------------------------------------------------

    As for the printf to debug you asked for, here are the results:

    I turned on all DBG flags and here's what I got between each 2 calls of the mqtt statemachine in mqtt-client.c, it is trying to connect but failing

    Connecting (1)
    process: calling process 'Event timer' with event 130
    process: calling process 'Ctimer process' with event 136
    process: calling process 'CC13xx / CC26xx RF driver' with event 130
    process: calling process 'Event timer' with event 130
    process: calling process 'ADC process' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'GPIO_read process' with event 136
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'TCP/IP stack', nevents 0
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'Ctimer process', nevents 0
    process: calling process 'Ctimer process' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'TCP/IP stack', nevents 0
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'TCP/IP stack', nevents 0
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'TCP/IP stack', nevents 0
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'TCP/IP stack', nevents 0
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'TCP/IP stack', nevents 0
    process: calling process 'TCP/IP stack' with event 136
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process: calling process 'Event timer' with event 130
    process_post: Process 'Event timer' posts event 136 to process 'CC26XX MQTT Client', nevents 0
    process: calling process 'CC26XX MQTT Client' with event 136
    DEBUG: state_machine, state=MQTT_CLIENT_STATE_CONNECTING
    Connecting (1)

  • No idea why the address changed. You might need to contact IBM.

  • Do you have a guide how to create an IBM organization (how to get this webpage: 65n4d9.messaging.internetofthings.ibmcloud.com ? 
    I think this is the only thing not found on the blog and hence I might have done sth wrong

    Here is what I did:

    I chose Internet of Things Platform

    and I didn't change anything here...

    Is that correct?

  • It looks fine to me.

  • Answer on IBM Watson Forum

    Answer by daniel.istrate@ymail.com (16) | Jul 22 at 03:11 AM

    I think that is expected due to load balancing and security. If you need a fixed IP then I think that would cost. If you are looking for a list with the used IPs you can check the below document:

    https://www.ibm.com/support/knowledgecenter/SSQP8H/iot/platform/reference/security/firewall_config.html


    - Is there a way to connect to the url directly without having to do the ip conversion? Is it implemented somewhere in contiki?

    - Are you able to ping your organization url and get a constant IP every time?

  • - Is there a way to connect to the url directly without having to do the ip conversion? Is it implemented somewhere in contiki?

    I have no experience on this but you can try to use resolv_lookup to lookup IPv6 address of url

    - Are you able to ping your organization url and get a constant IP every time?

    I think it's the same when I test this.

  • Do you mind sending me your hex file, and I try it on my node? Can you use those configs?

    #define IEEE802154_CONF_PANID 0xABCD
    #define IEEE802154_CONF_DEFAULT_CHANNEL 25
    #define RF_BLE_CONF_ENABLED 0 //1
    #define RPL_CONF_DEFAULT_LEAF_ONLY 0 // Low power mode, node does not participate in routing
    /*---------------------------------------------------------------------------*/

    /* Enable TCP */
    #define UIP_CONF_TCP 1

    /* Enable/Disable Components of this Demo */
    #define MQTT_CLIENT_CONF_WITH_IBM_WATSON 1
    #define CC26XX_WEB_DEMO_CONF_MQTT_CLIENT 1
    #define CC26XX_WEB_DEMO_CONF_6LBR_CLIENT ROUTING_CONF_RPL_CLASSIC
    #define CC26XX_WEB_DEMO_CONF_COAP_SERVER 0 //1
    #define CC26XX_WEB_DEMO_CONF_NET_UART 0 //1

  • What's this for? I haven't tested this for a while. If I do this, I just checkout the latest code and build it.

  • Just to make sure my code is not the issue ...

  • sorry forgot to mention, it should be rpl-classic to be used with 6lbr

    [INFO: Main ] Starting Contiki-NG-release/v4.2-291-g12cf5427f-dirty
    [INFO: Main ] - Routing: RPL Classic
    [INFO: Main ] - Net: sicslowpan
    [INFO: Main ] - MAC: CSMA
    [INFO: Main ] - 802.15.4 PANID: 0xabcd
    [INFO: Main ] - 802.15.4 Default channel: 25

  • Attach FW built with RPL Classic

    cc26x0-web-demo-RPL Classic-cc1350.zip

  • Thanks, doesn't work either ...

    The TCP dump on port 1883 shows nothing being transmitted : sudo tcpdump -i br0 -v -X port 1883

    I'll just try to get the quickstart working, do you know what should I write in the MQTT config page?

    Org ID:
    Auth Token:
    Command Type:
    Event Type ID:
    Interval (secs):
    Broker IP:
    Broker Port:

  • I haven't tested this IBM connection for a while.