-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nordic lighting app OnSRPClientNotification: [DL]Operation refused for security reasons #18507
Comments
I looked back at the Apple border router log and found that updates were rejected by the Apple border router as well, most likely for the same reason as #18737. Hence, this is no issue for Nordic platform. |
@Damian-Nordic Copied the packet #121 DNS records below.
|
@Damian-Nordic could you please take another look at this issue as this particular issues is causing several failures in our testing and in general is the root cause of poor pairing reliability on Nordic platform? |
@aajain-com The issue with sending PTR records with TTL=0 must be fixed in OpenThread before we can integrate it into the Nordic's SDK. Abtin commented in openthread/openthread#7742 that he would plan to take a look at that. Is there a confirmation from Apple Border Router developers that the records are the reason why the SRP update is rejected? |
@Damian-Nordic It was confirmed that if subtypes with TTL=0 are included, such update will be refused. |
@jwhui @abtink Could you help me understand if this issue has been addressed in OpenThread already? It was also mentioned by Ted Lemon in openthread/openthread#7742 (comment), and then I saw https://github.com/openthread/openthread/pull/7795/files, but I couldn't find any commits concerning the SRP client part. Also, I cannot find any conditions preventing the client to send subtypes with TTL=0 in https://github.com/openthread/openthread/blob/7e7da0e21149925d42f26f2e563e15c0b17226b2/src/core/net/srp_client.cpp#L1004. |
@Damian-Nordic, TLDR, I will add a PR in OT to change this to unblock this. Some thoughts on this:
Some background on this:
|
It seems pretty simple to just not emit the subtype if its lifetime is zero. |
Hi, I managed to test Apple border router with the Nordic Thread device containing the sub-type PTR removal fix from @abtink. It works better, as Apple border router accepts the service removal sent by the Matter firmware. Unfortunately it still rejects the removal using OpenThread CLI commands (ot srp client service remove ... ) with the same error message "[DL]Operation refused for security reasons". On the other hand service removal using both methods (by the Matter firmware and ot cli) works fine with the OpenThread Border Router, so still we have some behavior difference here. To discover the difference between Matter firmware and OT cli I gathered pcaps from Wireshark. It looks like the Matter firmware doesn't simply remove single service, but also by the way updates another services. OT cli srp remove command just removes the single service, so my assumption is that Apple Border Router rejects the SRP updates that contain only service removal operation. Please see the wireshark screenshots: SRP removal request by the OpenThread CLI remove command SRP removal request by the Matter firmware: @Abhayakara @kpark-apple do you have any ideas on why single remove operation could be rejected by the Apple TBR? |
It looks like the OT cli is removing the service PTR and service instance name and adding the host, so you have a host with no services after this is done. This should be okay. I don't know if you're able to send me un-redacted logs from your Thread BR (you'd have to run this with the debugging profile and then generate a sysdiagnose). Instructions for debugging profile here if you don't have them: https://download.developer.apple.com/iOS/tvOS_Logs/mDNSResponder_Logging_Instructions.pdf The instructions include how to generate a sysdiagnose and attach it e.g. to an email message or upload it. If you can do the above while reproducing the issue, I should be able to figure out why the update is being rejected by looking at the log. Bear in mind that all your DNS lookups are not private while this profile is installed. |
@Abhayakara thanks for confirming the procedure looks correct at first glance. Unfortunately I'm struggling with often stability issues related to the Matter beta firmware on iOS/tvOS, so basically setting things up and reproducing something takes me pretty lot of time. Currently I need to switch to another topic, so I will not be able to help in debugging for one or few days. @kpark-apple could you or somebody from Apple engineers that is more fluent with debugging your devices help on that? The steps to reproduce are very easy:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This stale issue has been automatically closed. Thank you for your contributions. |
Problem
Keep seeing the message in the above title when pairing Nordic lighting app and consequently failing the pairing.
It occurred with both commit 9cc0fb3 as well as with cfc3595.
Attached files are the Nordic log and Wireshark PCAP log, reproduced with cfc3595.
The problem occurred between 7:25:19am PDT and 7:26:15am PDT.
802.15.4 decryption key: B38E612D11DC3BB798545AA8BC1C9D07
Key index: 0
20220517-nordic-refused.txt
20220517-Nordic-operation-refused-for-security-reasons.pcapng.zip
Proposed Solution
N/A
The text was updated successfully, but these errors were encountered: