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.

CC2652RB: where are the OpenThread settings located in flash, like IPv6.. ? how to prevent getting a new IPv6 address?

Part Number: CC2652RB

currently i am flashing the same image over and over again, and the device is getting a new ipv6 address every time..

logs: 

[12:01:40] [fdde:ad00:beef:0:b6c9:102a:ddbf:9410]:5683 "dummy" {"temperature" : 1337 ,"battery" : 0 ,"euid" : "0x00124b00214f48b5"}
[12:02:32] [fdde:ad00:beef:0:7e9b:4b5e:41c5:e723]:5683 "dummy" {"temperature" : 1337 ,"battery" : 0 ,"euid" : "0x00124b00214f48b5"}
[12:03:08] [fdde:ad00:beef:0:a7ae:dbef:f249:9c25]:5683 "dummy" {"temperature" : 1337 ,"battery" : 0 ,"euid" : "0x00124b00214f48b5"}
[12:15:52] [fdde:ad00:beef:0:2038:4505:cf7f:459f]:5683 "dummy" {"temperature" : 1337 ,"battery" : 0 ,"euid" : "0x00124b00214f48b5"}
[12:16:13] [fdde:ad00:beef:0:83fc:28b2:2bd1:65f7]:5683 "dummy" {"temperature" : 1337 ,"battery" : 0 ,"euid" : "0x00124b00214f48b5"}

wondering where in flash exactly are those settings stored?

i am not clearly seeing where those flash is associated.. so i could skip it during flashing

even if i am not erasing the device and just flashing the same image, its still getting a new addres..

btw, my setup:

- flashing using the serial bootloader, using this tool: https://github.com/JelmerT/cc2538-bsl

- running a LAUNCHPAD as a border router and using wpantund to create a local network interface.

- a simple golang server is listening and printing the received coap-messages

- device is my custom design: https://www.tindie.com/products/slaesh/cc2652-zigbee-coordinator-or-openthread-router/ simply sending coap-messages on start and pressing a button

IMAGINE this scenario:

Device A wants to send a MSG to Device B.

Device A knows Device B's IPv6 addres..

Device B changes this address somehow?!

What should Device A do now? =/

  • guess i found it!

    linker file (CC2652RB_LAUNCHXL_TIRTOS.lds)

    .nvs (NOLOAD) : ALIGN(0x2000) {
    *(.nvs)
    } > REGION_TEXT

    ti_drivers_config.c

    __attribute__ ((section (".nvs")))
    static char flashBuf0[0x4000];
    

    anyway.. the question still exists!

    How can any device know the IPv6 address of any other device?

    the only known fixed value is the euid.. ?!

  • Hi,

    Thanks for sharing your finding of the section for the NV region.

    Discovery of devices should be implemented in the application: https://groups.google.com/forum/#!topic/openthread-users/fkA385Lyd_E

    That said, you could use something like DHCPv6, which has provisions for management (leasing, renewing, releasing, etc) of addresses.

    Regards,
    Toby

  • Thanks Toby for your fast reply and those hints!

    Do you have any starting point for me.. WHO is now assigning the ip's?

    - The NCP border router device?

    - wpantund?

    - my pc?

  • In addition to YK's post:

    A single Thread device may be identified by multiple IPv6 addresses, based on use case and scope.

    The device which initially forms a Thread network decides what the mesh-local prefix will be (see function otThreadSetExtendedPanId in thread_api.cpp).

    Afterwards, devices which join and commission are assigned addresses (in the structure of the link YK referenced).

    Since the Border Router serves as interface between a Thread network and non-Thread IP devices, it may allocate additional (globally-scoped) addresses for this purpose (e.g. as DHCPv6 server). The Border Router entity is composed of both the wpantund and NCP, with wpanctl offering various CLI commands (https://github.com/openthread/wpantund).

  • thanks for that informations!

    but i am still wondering.. imagine the following scenario:

    actor 1: light switch

    actor 2: the light

    i want to tell actor 1, that if he get switched, he should tell actor 2 to toggle the light!

    currently they are in the same room, near the same router, maybe one of those guys is even a router..

    but now i am moving my actor 1 into my small tiny wooden house in the garden. connected over another router..

    i dont want to pair them again, it should just work!

    without any border router.. just the network itself!

    isn't that possible with OT on the fly?

    i am not getting the two cents how i can "pair" to of these guys to know where to send its packets to..

    or do i need to send broadcasts all the time with the target in its payload.. seems like an overkill in a huge network..

    thanks! :)

  • Yes, route repair functionality is included in the spec.

    A device's mesh-local endpoint identifier (ML-EID) is meant to remain constant in the Thread network (and should be used by applications). How "pairing" is accomplished is up to the application's pairing logic.

    Assuming pairing is complete, actor 1 knows actor 2's ML-EID. In your example, actor 1 is moved such that its route to actor 2 may no longer be valid. The network layer (of actor 1 OR its parent) would then proceed to find a valid route to actor 2 (e.g. with ML-EID of actor 2).

  • thank you toby! exactly these were my missing two cents!

    of course, pairing is my (application's) part!

    love to start hacking