openthread: SRP Client on the accessory used incorrect srp server IP address

The SRP client uses an IP address that isn’t configured on the SRP server.

To Reproduce

Git commit id: d8a2cd9a70cfda7c2657645b4a57411eadaa4e61 Border router: Apple’s implementation of Duckhorn router running on Raspi pi 4 Model B Accessory: running on nordic nrf52840-DK

Expected behavior We expect the SRP client to use the address advertised in the network data

Console/log output

I: 48707 [DIS]Found admin paring for admin 0, node BC5C01
D: 48712 [DIS]Using Thread MAC for hostname.
I: 48717 [SVR]Device completed Rendezvous process
E: 48911 [DL]Long dispatch time: 264 ms
D: 48915 [DL]In DriveBLEState
D: 48918 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
D: 48926 [DL]OpenThread State Changed (Flags: 0x1104d11d)
D: 48931 [DL]   Device Role: DETACHED
D: 48935 [DL]   Network Name: OpenThread
D: 48938 [DL]   PAN Id: 0xABCD
D: 48941 [DL]   Extended PAN Id: 0xDEAD00BEEF00CAFE
D: 48946 [DL]   Channel: 11
D: 48948 [DL]   Mesh Prefix: fdde:ad00:beef::/64
D: 48953 [DL]   Thread Unicast Addresses:
D: 48956 [DL]        fdde:ad00:beef:0:c41c:d4a5:3f62:b55e/64 valid preferred
D: 48963 [DL]        fe80::14fd:46fd:1be9:34db/64 valid preferred
D: 49486 [DL]OpenThread State Changed (Flags: 0x00000100)
I: 50507 [DL]SRP Client was started, as detected server addressed: fdf2:7a68:5f3e:108c:0:ff:fe00:fc11
D: 50517 [DL]OpenThread State Changed (Flags: 0x301332b7)
D: 50522 [DL]   Device Role: CHILD
D: 50525 [DL]   Network Name: MyHomeBR
D: 50528 [DL]   PAN Id: 0xABCD
D: 50531 [DL]   Extended PAN Id: 0x949CD1F473FF7008
D: 50536 [DL]   Channel: 11
D: 50538 [DL]   Mesh Prefix: fdf2:7a68:5f3e:108c::/64
D: 50543 [DL]   Partition Id: 0x33AA34DE
D: 50547 [DL]   Thread Unicast Addresses:
D: 50551 [DL]        fd31:296e:280b:0:fd04:43b4:5bc1:85ca/64 valid preferred
D: 50558 [DL]        fdf2:7a68:5f3e:108c:0:ff:fe00:c04/64 valid preferred rloc
D: 50565 [DL]        fdf2:7a68:5f3e:108c:c41c:d4a5:3f62:b55e/64 valid preferred
D: 50572 [DL]        fe80::14fd:46fd:1be9:34db/64 valid preferred
I: 50578 [NP]Sending IP Address. Delegate 0x20005b8c
D: 50583 [IN]Secure message was encrypted: Msg ID 0
I: 50588 [IN]Sending msg from 0x0000000000bc5c01 to 0x0000000000000000 at utc time: 50588 msec
I: 50596 [IN]Sending secure msg on connection specific transport
D: 50602 [DL]Sending indication for CHIPoBLE TX characteristic (ConnId 0, len 20)
I: 50609 [IN]Secure msg send status No Error
D: 50613 [DL]OpenThread State Changed (Flags: 0x00000001)
D: 50619 [DL]   Thread Unicast Addresses:
D: 50622 [DL]        fd31:296e:280b:0:fd04:43b4:5bc1:85ca/64 valid preferred
D: 50629 [DL]        fdf2:7a68:5f3e:108c:0:ff:fe00:c04/64 valid preferred rloc
D: 50636 [DL]        fdf2:7a68:5f3e:108c:c41c:d4a5:3f62:b55e/64 valid preferred
D: 50643 [DL]        fe80::14fd:46fd:1be9:34db/64 valid preferred
I: 50649 [NP]Sending IP Address. Delegate 0x20005b8c
D: 50655 [IN]Secure message was encrypted: Msg ID 1
I: 50659 [IN]Sending msg from 0x0000000000bc5c01 to 0x0000000000000000 at utc time: 50659 msec
I: 50668 [IN]Sending secure msg on connection specific transport
I: 50673 [IN]Secure msg send status No Error
D: 50796 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
D: 50804 [DL]Write request received for CHIPoBLE RX characteristic (ConnId 0x00)
D: 50811 [DL]Sending indication for CHIPoBLE TX characteristic (ConnId 0, len 20)
D: 50891 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
D: 50899 [DL]Sending indication for CHIPoBLE TX characteristic (ConnId 0, len 20)
D: 50988 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
D: 50996 [DL]Write request received for CHIPoBLE RX characteristic (ConnId 0x00)
D: 51003 [DL]Sending indication for CHIPoBLE TX characteristic (ConnId 0, len 20)
D: 51085 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
D: 51093 [DL]Sending indication for CHIPoBLE TX characteristic (ConnId 0, len 9)
D: 51183 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
D: 51191 [DL]Write request received for CHIPoBLE RX characteristic (ConnId 0x00)
D: 51198 [DL]Sending indication for CHIPoBLE TX characteristic (ConnId 0, len 20)
D: 51281 [DL]ConnId: 0x00, New CCCD value: 0x0000
D: 51285 [DL]SetAdvertisingEnabled(false)
I: 51289 [SVR]Persisting admin ID 0, next available 1
I: 51481 [SVR]Persisting admin ID successfully
I: 51486 [SVR]OnRendezvousError: Ble Error 6004 (0x00001774): BLE central unsubscribed
I: 51494 [BLE]Releasing end point's BLE connection back to application.
E: 51500 [DL]Long dispatch time: 219 ms
D: 51504 [DL]Indication for CHIPoBLE TX characteristic done (ConnId 0x00, result 0x00)
E: 51511 [BLE]no endpoint for BLE sent data ack
D: 51516 [DL]In DriveBLEState
E: 52593 [DL]OnSrpClientNotification: Timed out waiting on server response
I: 53669 [DL]BLE GAP connection terminated (reason 0x13)
I: 53674 [DL]Current number of connections: 0/1
D: 53678 [DL]In DriveBLEState
E: 55686 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 60921 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 69794 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 84856 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 110423 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 153858 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 227671 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 353131 [DL]OnSrpClientNotification: Timed out waiting on server response
E: 566380 [DL]OnSrpClientNotification: Timed out waiting on server response

Here are the addresses configured on the Thread interface on the BR:

wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet6 fdf2:7a68:5f3e:108c:eba6:56f3:c6c2:9d91  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::e015:3479:fe5:62fb  prefixlen 64  scopeid 0x20<link>
        inet6 fdf2:7a68:5f3e:108c:0:ff:fe00:fc00  prefixlen 64  scopeid 0x0<global>
        inet6 fd31:296e:280b:0:4a1f:c44f:47e1:a17b  prefixlen 64  scopeid 0x0<global>
        inet6 fdf2:7a68:5f3e:108c:0:ff:fe00:fc10  prefixlen 64  scopeid 0x0<global>
        inet6 fdf2:7a68:5f3e:108c:0:ff:fe00:c00  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 83  bytes 4781 (4.6 KiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 24  bytes 3533 (3.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Additional context Add any other context about the problem here.

The code here seems to be constructing an address in a way that’s not valid and doesn’t actually produce an address that’s configured on the Border Router (SRP server):

https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L163

As you can see in the console output, the address is constructs is this:

fdf2:7a68:5f3e:108c:0:ff:fe00:fc11

This is a mesh-local address, which isn’t in the advertisement, and is not actually an address configured on the BR.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 16 (11 by maintainers)

Most upvoted comments

If we can signal the availability of anycast without advertising it as a service that might be better.

I’m not sure I understand the distinction between “anycast” and “service”. Is the goal generalize the anycast address to support more than just SRP?

I believe just signaling the availability of anycast in Thread requires the Service TLV mechanism. The Thread network data needs to include identifiers (RLOCs) for each of the border routers that are announcing the availability of anycast - it’s how Thread routers know where they can route anycast packets.

I think the best path forward is to just have two different Service TLVs. The “Service TLV” is just a name for a mechanism. The SRP client can then prefer anycast if present.

Anycast TLV:

  1. Type (1 byte)
  2. Length (1 byte)
  3. Flags (1 byte)
  4. Service Data Length (1 byte)
  5. Service Number (1 byte)
  6. SRP number for re-registration (1 byte)
  7. … Server TLVs …

SRP Infrastructure Service TLV:

  1. Type (1 byte)
  2. Length (1 byte)
  3. Flags (1 byte)
  4. Service Data Length (1 byte)
  5. Service Number (1 byte)
  6. IPv6 Address (16 bytes)
  7. Port (2 bytes)
  8. … Server TLVs …

Both would include the same Server TLVs that just encode the RLOC16s.

+2
jwhui on Apr 15, 2021

It’s going to be necessary to be able to advertise an SRP service that’s not on the Thread network at all, so it makes sense to support the ability to choose a server that’s got an IPv6 address that’s not mesh-local and not anycast.

In the spirit of minimizing optionality, what about having the border router serve as a proxy when the SRP service is not on the Thread network? Thread devices then only need to worry about the anycast address and the network data is more compact. In either case, the border router will need to know the IP and port of the SRP service.

+2
jwhui on Apr 14, 2021
Read more comments on GitHub
← openthread: SED gets stuck with wrong RLOC address
openthread: WPANTUND fails to initialize nrf52840-mdk →