[chip-tool] Restart address update on failure #11779
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pullapprove
bot
requested review from
anush-apple,
balducci-apple,
bzbarsky-apple,
carol-apple,
cecille,
chrisdecenzo,
chulspro,
electrocucaracha,
emargolis,
erjiaqing,
franck-apple,
hawk248,
jelderton,
jepenven-silabs,
jmartinez-silabs,
kghost,
LuDuda,
lzgrablic02,
mlepage-google,
mrjerryjohns,
msandstedt,
pan-apple,
sagar-apple,
saurabhst,
selissia,
tcarmelveilleux,
tecimovic,
turon and
vivien-apple
pullapprove
bot
requested review from
wbschiller,
woody-apple and
yunhanw-google
|
PR #11779: Size comparison from 5623978 to cd268ff Decreases (1 build for linux)
Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
|
Our address resolution timeout is 10s - is it actually taking that long for these devices to come online, we should move this retry into the SDK itself or make the timeout adjustable. The node resolve actually happens as a part of the IP commissioning process as well. Do we need to add a retry there as well, or is that not required for devices that are already on the network? The calls that happen as a part of chip tool are only for BLE commissioning (currently). Is this issue happening just as a part of the network startup? |
|
@cecille Normally, it doesn't take that long, but on some setups that involve Sleepy End Devices and OTBR running on a Raspberry Pi it does seem to take even more than 10s. Also, you're probably talking about the miminal mDNS resolver (right?), while other platforms may use different timeouts. Avahi seems to use something around 5s and I can't find API to change that. I'm not sure about IP commissioning, but I guess it should take less time to update DNS-SD info in such a case. I'm open to recommendations if you know a place in the SDK code where we could add the code, but I think not all |
andy31415
reviewed
Nov 15, 2021
vivien-apple
approved these changes
Nov 15, 2021
|
@Damian-Nordic - TE7 cherrypicks are closed, however we can put this on the TE7.lts branch once it is merged if you want. |
|
@andy31415 Oh, I somehow missed that. Then we will probably need recommending some hacks on the firmware side to people who experience commissioning failures with chip-tool during TE7. |
For some devices, it may take more time to appear on the network and become discoverable over DNS-SD, so don't give up on the address resolution failure and restart the address update.
Damian-Nordic
force-pushed
the
chip-tool-long-resolve
branch
from
cd268ff to
3987c55
Compare
|
PR #11779: Size comparison from 7c47bed to 3987c55 Decreases (1 build for linux)
Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
woody-apple
approved these changes
Nov 15, 2021
|
Fast tracking, given this is adding to a test tool. |
andy31415
approved these changes
Nov 15, 2021
ghost
mentioned this pull request
PSONALl
pushed a commit
to PSONALl/connectedhomeip
that referenced
this pull request
Dec 3, 2021
For some devices, it may take more time to appear on the network and become discoverable over DNS-SD, so don't give up on the address resolution failure and restart the address update.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
For some devices, it may take more time to appear on the network and become discoverable over DNS-SD. Some users reported issues with
chip-toolfailing to discover an address of a Thread Sleepy End Device because of certain delays in an SRP update processing. Consequently, they had to restart the entire commissioning to move on.Change overview
Don't give up on the address resolution failure and restart the address update.
Testing
Tested using
chip-tooland a Thread device by manually delaying the OTBR start.