-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Implement and publish mDNS on esp32 #3452
Conversation
8849a42
to
d28f044
Compare
examples/temperature-measurement-app/esp32/main/ResponseServer.cpp
Outdated
Show resolved
Hide resolved
exit: | ||
if (items != nullptr) | ||
{ | ||
chip::Platform::MemoryFree(items); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be allocated on the stack, I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
items
is an array with variable length so we need to allocate from heap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C++ stack allocation based on a parameter works fine (just don't use sizeof() on the resulting space :-( )
alloca.cpp:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, const char * const * argv)
{
int len = atoi(argv[1]);
char before[1];
char buf[len];
char after[1];
printf("before: %p\n"
"buf: %p\n"
"after: %p\n"
"sizeof(buf): %zu\n",
before, buf, after, sizeof(buf));
return 0;
}
$ g++ --std=c++11 alloca.cpp -o alloca && ./alloca 0x100
before: 0x7ffeee3169f3
buf: 0x7ffeee3169b0
after: 0x7ffeee3169df
sizeof(buf): 0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a non-standard extension and fails if you build with -Wvla
, though.
return error; | ||
} | ||
|
||
CHIP_ERROR ChipMdnsStopPublish() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed there's no "remove service" API at the CHIP level. how will we handle temporary registrations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, will add in other PR.
src/lib/protocols/mdns/Publisher.cpp
Outdated
|
||
CHIP_ERROR Publisher::Init() | ||
{ | ||
return ChipMdnsInit(HandleMdnsInit, HandleMdnsError, this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this implies that Publisher can be the only client of ChipMdns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We can add new methods to this class for future feature requests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Publisher
class. I plan to handle all the service registration things here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec for discovery is already merged. The format should match the available spec text.
src/lib/protocols/mdns/Publisher.cpp
Outdated
VerifyOrExit(mInitialized, error = CHIP_ERROR_INCORRECT_STATE); | ||
ChipLogProgress(Discovery, "setup mdns service"); | ||
SuccessOrExit(error = chip::DeviceLayer::ConfigurationMgr().GetSetupDiscriminator(discriminator)); | ||
sprintf(service.mName, "CHIP-%04d", discriminator); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This type of non-length-limited (e.g, sprintf/strcpy instead of snprintf/strncpy) is strongly discouraged. Pigweed's pw_string
module has super-lightweight safe wrappers to do string formatting and concatenation over char arrays that is size-safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CHIP-xxxx is not the correct format. The format is settled, see https://github.com/CHIP-Specifications/connectedhomeip-spec/pull/247
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The publish format has been modified according to the spec. However, subtypes are not supported well in embedded systems (esp and lwip). We currently only publish the xxxxx._chipc._udp
entry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that lwip and ESP default mDNS libraries are insufficient is separate from whether the codebase should support what the spec defines. I think it would be straightforward to use a separate good-features mDNS library on embedded to avoid hitting different limitations of underlying platforms that today provide extremely limited mDNS/DNS-SD support.
src/platform/ESP32/MdnsImpl.cpp
Outdated
return mdns_service_remove_all() == ESP_OK ? CHIP_NO_ERROR : CHIP_ERROR_INTERNAL; | ||
} | ||
|
||
CHIP_ERROR ChipMdnsBrowse(const char * type, MdnsServiceProtocol protocol, chip::Inet::InterfaceId interface, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strongly recommend against browsing on embedded device. If it is done, it should be done with unicast-only bit set in request. Is this possible to do with the mDNS library used?
c992b1b
to
536d81b
Compare
char hostname[13]; // Hostname will be the hex representation of mac. | ||
CHIP_ERROR error; | ||
|
||
SuccessOrExit(error = chip::DeviceLayer::ConfigurationMgr().GetPrimaryWiFiMACAddress(mac)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only works for Wifi, not thread. Thread EIDs are 64 bits. There should be no Wifi config directly read from common mDNS publisher, since for Ethernet based devices, there won't be a Wifi address. Please have a configuration method for MAC address (which may rotate over time, as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current platform api only provides Thread EID and wifi mac address. I prefer to update the paltform api to provide meta information about the underlying connectivity (Thread/wifi/Ethernet enabled or not).
MdnsService service; | ||
CHIP_ERROR error = CHIP_NO_ERROR; | ||
|
||
SuccessOrExit(error = chip::DeviceLayer::ConfigurationMgr().GetFabricId(fabricId)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is again something that should likely not use singleton values, but have them passed down, in case the multiadmin conversations boil down to having > 1 device ID per physical node (which is not impossible).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also prefer to modify the platform api to iterate through the fabric/device ids.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved based on offline conversations that this PR is OK for demos, but there will need to be improvements to make the DNS-SD subsystem more scalable and have less assumptions.
Please fix the VID/PID format.
Size increase report for "esp32-example-build" from 6a5b193
Full report output
|
Size increase report for "nrfconnect-example-build" from 6a5b193
Full report output
|
Size increase report for "gn_qpg6100-example-build" from 6a5b193
Full report output
|
please move src/lib/protocols/mdns/ to src/lib/mdns. The directory src/lib/protocols/ is hosting Weave profiles, not network protocols. Those two directories src/lib/protocols/ and src/lib/message contain the wml based messaging stack, we plan to clean them up after we cherry pick all features to current messaging stack. |
Problem
mDNS is not implemented on esp32 platform.
Summary of Changes