[zephyr] Fix Network Commissioning after switching to new API #14891
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
New Network Commissioning cluster code using the generic Thread driver requires that kThreadConnectivityChange event be generated when the device is attached to a Thread network and that was only implemented for LWIP and Linux platforms. Fill the gap for Zephyr. Also, allow to use operational dataset without the network name as that is not neccessary to attach to a network. Signed-off-by: Damian Krolik <[email protected]>
pullapprove
bot
requested review from
andy31415,
anush-apple,
balducci-apple,
Byungjoo-Lee,
bzbarsky-apple,
carol-apple,
cecille,
chrisdecenzo,
chshu,
chulspro,
dhrishi,
electrocucaracha,
erjiaqing,
franck-apple,
gjc13,
hawk248,
holbrookt,
harsha-rajendran,
isiu-apple,
jelderton,
jepenven-silabs,
jmartinez-silabs,
kghost and
kpschoedel
pullapprove
bot
requested review from
msandstedt,
robszewczyk,
sagar-apple,
saurabhst,
selissia,
tecimovic,
turon,
vijs,
vivien-apple,
wbschiller,
woody-apple,
xylophone21 and
yufengwangca
andy31415
approved these changes
Feb 8, 2022
harsha-rajendran
approved these changes
Feb 8, 2022
msandstedt
approved these changes
Feb 8, 2022
|
Do we know when Thread commissioning broke? |
|
PR #14891: Size comparison from 092e707 to 13b5cd3 Increases (10 builds for nrfconnect, telink)
Decreases (20 builds for cyw30739, efr32, k32w, linux, qpg)
Full report (43 builds for cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
Likely when we started checking feature maps to determine which network type support exists. This was also parallel with requiring the "new" network commissioning cluster to be implemented (i.e. one that supports scanning and other spec-compliant functionality). To fix, we implemented a generic "new" thread network commissioning and this PR starts fixing that implementation. |
woody-apple
approved these changes
Feb 8, 2022
|
Yes, Andy is right. Basically, the new network commissioning API waits for the network attachment before sending a response to ConnectNetwork command and an event used to announce the network attachment was unimplemented in Zephyr. |
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
New Network Commissioning cluster code using the generic Thread driver requires that
kThreadConnectivityChangeeventbe generated when the device is attached to a Thread network, and that was only implemented for LWIP and Linux platforms.
Change overview
Fill the gap for Zephyr.
Also, allow to use operational dataset without the network name as that is not necessary to attach to a network.
Testing
Tested that commissioning works again on nRF Connect platform.