[mdns] Spawn kDnssdInitialized event after initializing mDNS server #25050
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
amitnj,
andy31415,
anush-apple,
arkq,
Byungjoo-Lee,
bzbarsky-apple,
carol-apple,
chrisdecenzo,
chshu,
chulspro,
dhrishi,
electrocucaracha,
emargolis,
franck-apple,
gjc13,
harimau-qirex,
harsha-rajendran,
hawk248,
jelderton,
jepenven-silabs,
jmartinez-silabs,
jmeg-sfy,
jtung-apple,
kcoppock and
ksperling-apple
pullapprove
bot
requested review from
robszewczyk,
saurabhst,
selissia,
tcarmelveilleux,
tecimovic,
tehampson,
vijs,
vivien-apple,
woody-apple,
xylophone21 and
yufengwangca
It turns out that when no network interfaces are up MinMdnsResolver::IsInitialized() returns false even after calling MinMdnsResolver::Init(). Moreover, the application has no means to be notified when the resolver gets ready to process DNS-SD queries. Rename kDnssdPlatformInitialized event to kDnssdInitialized and spawn it in the minimal mDNS implementation when the server becomes initialized, similarly to what the platform DNS-SD implementation does. This is needed to have a consistent way to notify the application that it can begin communication with other nodes e.g. to resume persistent subscriptions. Signed-off-by: Damian Krolik <[email protected]>
Damian-Nordic
force-pushed
the
mdns-init-event
branch
from
b93df7c to
d57bb13
Compare
|
PR #25050: Size comparison from 6ce0f90 to d57bb13 Increases above 0.2%:
Increases (33 builds for bl602, bl702, cc13x2_26x2, cc32xx, cyw30739, efr32, linux, mbed, psoc6, qpg, telink)
Decreases (12 builds for bl702, cc13x2_26x2, psoc6)
Full report (35 builds for bl602, bl702, cc13x2_26x2, cc32xx, cyw30739, efr32, linux, mbed, psoc6, qpg, telink)
|
bzbarsky-apple
approved these changes
Feb 14, 2023
There was a problem hiding this comment.
So with this change, what I see during startup is:
I (2639) chip[DL]: IPv4 address changed on WiFi station interface: 10.0.0.30/255.255.255.0 gateway 10.0.0.1
...
I (2669) app-devicecallbacks: IPv4 Server ready...
...
I (2699) chip[DIS]: CHIP minimal mDNS started advertising.
(multiple StartServer calls happen here, two for "reasons" and one because this PR triggers a StartServer from inside StartServer, so we do the "shut down and reinit endpoints" thing three times).
E (2819) chip[SVR]: Server initialization complete
Then we kick off the subscription resumption machinery, discovery happens, and then:
I (3159) chip[SC]: Initiating session on local FabricIndex 1 from 0x0000000000000011 -> 0x000000000001B669
I (3479) chip[EM]: <<< [E:24491i S:0 M:157468918] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:30 (SecureChannel:CASE_Sigma1)
I (3489) chip[IN]: (U) Sending msg 157468918 to IP address 'UDP:[FE80::18C8:1739:6AFD:1BC1%st1]:62231'
E (3509) chip[DMG]: Failed to establish CASE for subscription-resumption with error '3000004'
which is the LwIP ERR_RTE error, as far as I can tell. Because we just tried to send an IPv6 message but we have no IPv6 interface up. Then after that:
I (4139) chip[DL]: IP_EVENT_GOT_IP6
I (4139) chip[DL]: IPv6 addr available. Ready on WIFI_STA_DEF interface: fe80:0000:0000:0000:fef5:c4ff:fe30:e4e4
and after that we restart mDNS advertising again, but no longer trigger subscription resumption...
This part was likely broken even before #24725, since that didn't wait for network bringup at all. Now we're waiting until IPv4 comes up, but should really be waiting until all our interfaces are up, ideally... @jtung-apple @wqx6
andy31415
approved these changes
Feb 14, 2023
lecndav
pushed a commit
to lecndav/connectedhomeip
that referenced
this pull request
Mar 22, 2023
…roject-chip#25050) It turns out that when no network interfaces are up MinMdnsResolver::IsInitialized() returns false even after calling MinMdnsResolver::Init(). Moreover, the application has no means to be notified when the resolver gets ready to process DNS-SD queries. Rename kDnssdPlatformInitialized event to kDnssdInitialized and spawn it in the minimal mDNS implementation when the server becomes initialized, similarly to what the platform DNS-SD implementation does. This is needed to have a consistent way to notify the application that it can begin communication with other nodes e.g. to resume persistent subscriptions. Signed-off-by: Damian Krolik <[email protected]>
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.
It turns out that when no network interfaces are up MinMdnsResolver::IsInitialized() returns false even after calling MinMdnsResolver::Init(). Moreover, the application has no means to be notified when the resolver gets ready to process DNS-SD queries.
Rename kDnssdPlatformInitialized event to kDnssdInitialized and spawn it in the minimal mDNS implementation when the server becomes initialized, similarly to what the platform DNS-SD implementation does.
This is needed to have a consistent way to notify the application that it can begin communication with other nodes e.g. to resume persistent subscriptions.
Related to #25013