OpenThread
-
|
I am seeing an issue with SRP service registration seeming to timeout & looking for some general debugging tips to better understand what is going wrong. Or maybe just clarification on what is the expected client behavior for finalizing a registration request. The code I have is for a fairly simple MTD, which is acting as an SRP client that performs service registration after having an RLOC assigned. SRP service registration seems to work but only superficially: I see in the After the service is added (e.g. control flow returns from the But even so, the service still seems to be published? Or maybe I am misunderstanding something fundamental here. This is the output while tailing the logs right when starting up the MTD (with Also strangely get the same callback error (28) when the code proceeds to attempt to unregister the service and the host as well, which also superficially seems to work (but enters a similar retry state): Other potentially relevant details:
Is there some specific OT function that needs to be called to finalize the registration after By the way, if it is helpful I can provide code snippets for the MTD if needed, its just written in Rust so it will probably look a bit weird (Im using generated C++ bindings to call into statically linked ot libs). Can also provide cmake build options if that is helpful to know, too. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
@nand-nor , the server-side logs look good and show that the client's SRP registration message is successfully parsed and processed, and a success response is sent back to the client. It appears the client either doesn't receive the response or rejects it, triggering a response timeout error and causing the client to retry registration. The increasing delay between client attempts is intended behavior. I would suggest Investigating further on the MTD side, to determine why it might not be receiving or rejecting the response. If you can collect the ogs from the MTD side, they may shed some light on this. BTW, from server/parent log I guess/assume the MTD is not sleepy.
No action or API is needed on the client side. The client will prepare and send the registration once all of the following conditions are met. It adds a short delay in case the caller is registering multiple services (multiple calls to
|
Beta Was this translation helpful? Give feedback.
-
|
Ah got it, thank you @abtink for verifying that at least server side everything looks OK and that nothing else should be needed client side after adding the service. Sounds like I need to grab some pcaps and see if/how the device is receiving response packets as a next step. I sadly currently do not have access to logging within the OT libs because of the experimental nature of the platform I am building on so somewhat blind in that sense, at least until I sort that out. One follow up question is, are the initial responses from the SRP server encrypted with the SRP key? Ive not yet added the logic to store that key in NVM. I know this will cause issues on a power event not storing the key in NVM, but in theory barring a power event no other special key handling in the application layer should be required right? Or am I misunderstanding? Another follow up question: given the delay that is added to ensure all services are registered together, is it fair to then assume that for devices running a single threaded application with minimal locks, they should hold off on processing/calling certain OT functions during that window of delay time? Specifically I mean executing any OT function that takes as an arg a mutable pointer to the OT instance, or, in C++ terms, takes a pointer to the OT instance and executes logic that can in any way mutate the OT instance / mutate any of the data owned or managed by the OT instance etc. I assume servicing platform alarm callbacks should be ok, more thinking about processing tasklets or opening a As an aside someday (very soon) I know this will need to be run on top of something like an RTOS or with async executors where OT runs on a dedicated core, but for now its all running bare metal. So I wonder if I need something at this point to guard OT instance pointer accesses during that delay window from across the Rust/C++ FFI boundary. Also you are correct, the device is not sleepy / rx should always be on when idle. Worth noting that in general the device is in very early development/experimental stages so many other things could be going wrong here (for example the lack of an RTOS). |
Beta Was this translation helpful? Give feedback.
-
No. The SRP key is only used for the ECDSA signature (the client appends it to its SRP update message, and the server validates it).
I agree; it should not matter (at least for processing the SRP update response). But if
No, I don't think there is any restriction on this. The OT stack generally requires that all its APIs (public or platform APIs and callbacks) be called from the same OS context (e.g., the same thread or RTOS task). Beyond this, there is no restriction (i.e., any API/callback can be called after the "add service API" call). |
Beta Was this translation helpful? Give feedback.
-
|
Got it, thanks very much @abtink . Marking as answered since my main question was covered, and thanks for the details on the follow up questions. |
Beta Was this translation helpful? Give feedback.
@nand-nor , the server-side logs look good and show that the client's SRP registration message is successfully parsed and processed, and a success response is sent back to the client.