Skip to content
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

Merged
merged 3 commits into from
Oct 29, 2020
Merged

Conversation

gjc13
Copy link
Contributor

@gjc13 gjc13 commented Oct 27, 2020

Problem

mDNS is not implemented on esp32 platform.

Summary of Changes

  • Implement the platform mDNS api on esp32.
  • Add publisher api.
  • Publish device information via mDNS.

exit:
if (items != nullptr)
{
chip::Platform::MemoryFree(items);
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

@rwalker-apple rwalker-apple Oct 28, 2020

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

Copy link
Contributor

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()
Copy link
Contributor

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?

Copy link
Contributor Author

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.


CHIP_ERROR Publisher::Init()
{
return ChipMdnsInit(HandleMdnsInit, HandleMdnsError, this);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which class?

Copy link
Contributor Author

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.

Copy link
Contributor

@tcarmelveilleux tcarmelveilleux left a 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.

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);
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

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,
Copy link
Contributor

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?

@gjc13 gjc13 force-pushed the esp-mdns branch 3 times, most recently from c992b1b to 536d81b Compare October 28, 2020 10:52
char hostname[13]; // Hostname will be the hex representation of mac.
CHIP_ERROR error;

SuccessOrExit(error = chip::DeviceLayer::ConfigurationMgr().GetPrimaryWiFiMACAddress(mac));
Copy link
Contributor

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).

Copy link
Contributor Author

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));
Copy link
Contributor

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).

Copy link
Contributor Author

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.

Copy link
Contributor

@tcarmelveilleux tcarmelveilleux left a 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.

@github-actions
Copy link

Size increase report for "esp32-example-build" from 6a5b193

File Section File VM
chip-wifi-echo.elf .flash.text 22144 22144
chip-wifi-echo.elf .dram0.bss 0 1904
chip-wifi-echo.elf .flash.rodata 676 676
chip-wifi-echo.elf [2 Others] 48 8
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

sections,vmsize,filesize
.debug_info,0,250452
.debug_line,0,89699
.debug_loc,0,39035
.flash.text,22144,22144
.debug_abbrev,0,13813
.debug_str,0,10389
.debug_ranges,0,3704
.strtab,0,3655
[Unmapped],0,3412
.debug_frame,0,3260
.symtab,0,2160
.dram0.bss,1904,0
.debug_aranges,0,1216
.shstrtab,0,757
.flash.rodata,676,676
.xt.prop._ZN4chip11DeviceLayer8Internal31GenericConfigurationManagerImplINS0_24ConfigurationManagerImplEE24_GetManufacturerDeviceIdERy,0,100
.xt.prop._ZN4chip11DeviceLayer8Internal31GenericConfigurationManagerImplINS0_24ConfigurationManagerImplEE12_GetFabricIdERy,0,88
.xt.prop._ZN4chip11DeviceLayer8Internal31GenericConfigurationManagerImplINS0_24ConfigurationManagerImplEE12_GetDeviceIdERy,0,76
.xt.lit._ZN4chip11DeviceLayer8Internal31GenericConfigurationManagerImplINS0_24ConfigurationManagerImplEE12_GetFabricIdERy,0,48
.xt.lit._ZN4chip11DeviceLayer8Internal31GenericConfigurationManagerImplINS0_24ConfigurationManagerImplEE24_GetManufacturerDeviceIdERy,0,48
[2 Others],8,48


@github-actions
Copy link

Size increase report for "nrfconnect-example-build" from 6a5b193

File Section File VM
chip-shell.elf rodata 8 4
chip-lock.elf rodata 8 4
chip-lighting.elf rodata 8 4
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-shell.elf and ./pull_artifact/chip-shell.elf:

sections,vmsize,filesize
.debug_info,0,111
.debug_str,0,21
rodata,4,8
.debug_line,0,1
.debug_loc,0,-5

Comparing ./master_artifact/chip-lock.elf and ./pull_artifact/chip-lock.elf:

sections,vmsize,filesize
.debug_info,0,183
.debug_str,0,21
rodata,4,8
.debug_line,0,1
.debug_loc,0,-5

Comparing ./master_artifact/chip-lighting.elf and ./pull_artifact/chip-lighting.elf:

sections,vmsize,filesize
.debug_info,0,183
.debug_str,0,21
rodata,4,8
.debug_line,0,1
.debug_loc,0,-5


@github-actions
Copy link

Size increase report for "gn_qpg6100-example-build" from 6a5b193

File Section File VM
chip-qpg6100-lock-example.out .rodata 4 4
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-qpg6100-lock-example.out and ./pull_artifact/chip-qpg6100-lock-example.out:

sections,vmsize,filesize
.debug_info,0,87
.debug_str,0,18
.rodata,4,4
.debug_loc,0,-1
[Unmapped],0,-4


@yufengwangca
Copy link
Contributor

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.

@mspang mspang merged commit 5ad6518 into project-chip:master Oct 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants