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

Make CHIP devices advertise as operational devices via mDNS #4132

Merged
merged 26 commits into from
Dec 11, 2020

Conversation

andy31415
Copy link
Contributor

Problem

Need CHIP devices to respond to mDNS properly.

Summary of Changes

Replaces DiscoveryManager (which has avahi/esp32 implementation only) with an abstracted-away minMDNS implementation for advertising. Tested via:

andrei@Andreis-Mac-mini ~ % dns-sd -B _chip._tcp                 
Browsing for _chip._tcp
DATE: ---Tue 08 Dec 2020---
16:27:39.955  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
16:27:40.157  Add        2   4 local.               _chip._tcp.          14A77CBB3-BC5C01
^C
andrei@Andreis-Mac-mini ~ % dns-sd -L 14A77CBB3-BC5C01 _chip._tcp       
Lookup 14A77CBB3-BC5C01._chip._tcp.local
DATE: ---Tue 08 Dec 2020---
16:27:44.658  ...STARTING...
16:27:44.872  14A77CBB3-BC5C01._chip._tcp.local. can be reached at 14A77CBB3-BC5C01.local.:11097 (interface 4)
 =
^C
andrei@Andreis-Mac-mini ~ % dns-sd -G v4v6 14A77CBB3-BC5C01.local            
DATE: ---Tue 08 Dec 2020---
16:27:50.531  ...STARTING...
Timestamp     A/R    Flags if Hostname                               Address                                      TTL
16:27:50.752  Add        3  4 14A77CBB3-BC5C01.local.                FE80:0000:0000:0000:9AF4:ABFF:FE6B:1AFC%en0  30
16:27:50.752  Add        2  4 14A77CBB3-BC5C01.local.                10.0.0.200                                   30
^C
andrei@Andreis-Mac-mini ~ % ping6 FE80:0000:0000:0000:9AF4:ABFF:FE6B:1AFC%en0
PING6(56=40+8+8 bytes) fe80::1823:ac1e:caee:43c2%en0 --> fe80::9af4:abff:fe6b:1afc%en0
16 bytes from fe80::9af4:abff:fe6b:1afc%en0, icmp_seq=0 hlim=255 time=72.875 ms
16 bytes from fe80::9af4:abff:fe6b:1afc%en0, icmp_seq=1 hlim=255 time=92.139 ms
^C
--- FE80:0000:0000:0000:9AF4:ABFF:FE6B:1AFC%en0 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 72.875/82.507/92.139/9.632 ms
andrei@Andreis-Mac-mini ~ % ping 10.0.0.200                                  
PING 10.0.0.200 (10.0.0.200): 56 data bytes
64 bytes from 10.0.0.200: icmp_seq=0 ttl=255 time=21.517 ms
64 bytes from 10.0.0.200: icmp_seq=1 ttl=255 time=35.868 ms
^C
--- 10.0.0.200 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.517/28.693/35.868/7.175 ms

@andy31415
Copy link
Contributor Author

Had a few bugfixes: invalid && return for builders, created separatte packetbuffer copy for every broadcast packet.

@andy31415
Copy link
Contributor Author

Now that I started using minMDNS beyond hardcoded examples, I expect I will want a few passes to make it a bit nicer (constructor addresses and settings seem hard to follow).

For now I take this as 'this works' and then will iterate to add 'commisioning advertising' and make the thing a bit more readable.

In parallel we can build the platform-dependent mDNS version (avahi and esp32 if applicable). minMDNS tries hard to only use static memory and never dynamic, which has sideffects in how pretty the code is.

@boring-cyborg boring-cyborg bot added the system label Dec 9, 2020
@pullapprove pullapprove bot requested a review from pan-apple December 9, 2020 16:10
{
char buff[32];
snprintf(buff, sizeof(buff), "%d", value);
buff[sizeof(buff) - 1] = 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 one isn't necessary

also the largest int value should consume less than 32 bytes :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right ... even 64-bit is 20 chars at most. Wanted to not think about it since I imagine this code will be copied and pasted as if we ever want to format additional value types in here.

Do you think it would be useful to drop the line or are ok to keep as is?

src/lib/mdns/Advertiser_ImplMinimalMdns.cpp Outdated Show resolved Hide resolved
src/lib/mdns/BUILD.gn Outdated Show resolved Hide resolved
@@ -536,5 +536,31 @@ PacketBufferHandle PacketBufferHandle::PopHead()
return PacketBufferHandle(head);
}

PacketBufferHandle PacketBufferHandle::CloneData()
{
if (!mBuffer->Next().IsNull())
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this be an assertion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am unsure how assertions work. nlASSERT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All asserts in this file seem to be static. nlASSERT seem to be a noop in production (really? that seems odd, but this is what following #define seems to give me).

I would rather keep it as is as empty return.

@github-actions
Copy link

Size increase report for "nrfconnect-example-build" from 0998211

File Section File VM
chip-lighting.elf text 6956 6956
chip-lighting.elf rodata 1272 1272
chip-lighting.elf bss 0 992
chip-lighting.elf init_array 8 8
chip-lighting.elf shell_root_cmds_sections -4 -4
chip-lock.elf text 6956 6956
chip-lock.elf rodata 1272 1276
chip-lock.elf bss 0 992
chip-lock.elf init_array 8 8
chip-lock.elf shell_root_cmds_sections -4 -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,2990
.debug_line,0,664
.debug_abbrev,0,594
.debug_loc,0,514
.debug_ranges,0,256
.debug_str,0,102
.debug_frame,0,32
.debug_aranges,0,8

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

sections,vmsize,filesize
.debug_info,0,292204
.debug_line,0,50312
.debug_loc,0,32306
.debug_abbrev,0,31048
.debug_str,0,29342
.debug_ranges,0,13280
.strtab,0,9100
text,6956,6956
.symtab,0,5568
.debug_frame,0,3828
.debug_aranges,0,1320
rodata,1272,1272
bss,992,0
init_array,8,8
shell_root_cmds_sections,-4,-4

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

sections,vmsize,filesize
.debug_info,0,292306
.debug_line,0,50318
.debug_loc,0,32302
.debug_abbrev,0,31088
.debug_str,0,29342
.debug_ranges,0,13280
.strtab,0,9100
text,6956,6956
.symtab,0,5568
.debug_frame,0,3828
.debug_aranges,0,1320
rodata,1276,1272
bss,992,0
init_array,8,8
shell_root_cmds_sections,-4,-4


@github-actions
Copy link

Size increase report for "esp32-example-build" from 0998211

File Section File VM
chip-all-clusters-app.elf .flash.text 8164 8164
chip-all-clusters-app.elf .flash.rodata 1540 1540
chip-all-clusters-app.elf .dram0.bss 0 992
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-all-clusters-app.elf and ./pull_artifact/chip-all-clusters-app.elf:

sections,vmsize,filesize
.debug_info,0,282612
.debug_line,0,70933
.debug_abbrev,0,31908
.debug_loc,0,30092
.debug_str,0,29507
.debug_ranges,0,12696
.strtab,0,9322
.flash.text,8164,8164
.shstrtab,0,5802
[57 Others],0,4480
.symtab,0,4240
.debug_frame,0,3544
[Unmapped],0,2556
.flash.rodata,1540,1540
.debug_aranges,0,1296
.dram0.bss,992,0
.xt.lit._ZN4mdns7Minimal14ResponseSenderD5Ev,0,568
.xt.prop._ZN4chip8Encoding16BufferWriterBaseINS0_9BigEndian12BufferWriterEE3PutEPKc,0,380
.xt.prop._ZN4mdns7Minimal13IPv6ResponderD2Ev,0,236
.xt.prop._ZNK4mdns7Minimal23SerializedQNameIterator3PutERN4chip8Encoding9BigEndian12BufferWriterE,0,232
.xt.prop._ZN4chip8Encoding16BufferWriterBaseINS0_9BigEndian12BufferWriterEE3PutEPKvj,0,208


@bzbarsky-apple
Copy link
Contributor

@andy31415 Is the size of the codesize increase here about as expected?

@andy31415
Copy link
Contributor Author

@andy31415 Is the size of the codesize increase here about as expected?

I don't have much control on the sizes. Flash/txt seems ok, BSS size seems a bit large. I expect as we iterate we may find places where we can decrease things.

@andy31415 andy31415 merged commit 27d3ea8 into project-chip:master Dec 11, 2020
kpschoedel added a commit to kpschoedel/connectedhomeip that referenced this pull request Dec 14, 2020
kpschoedel added a commit to kpschoedel/connectedhomeip that referenced this pull request Jan 8, 2021
andy31415 pushed a commit that referenced this pull request Jan 8, 2021
* SystemPacketBuffer.h cleanup

#### Problem

Code should use `PacketBufferHandle` rather than `PacketBuffer *`.
Some existing methods should be removed or made private so that code
does not have unnecessary access to the raw pointer.

#### Summary of Changes

- convert public use of `PacketBufferHandle::Adopt()`.
- convert internal use of `Adopt()` to private `Free()`.
- renamed `PacketBuffer::Create()` factory to `Adopt()`.
- rename private `PacketBuffer::Next()` to `ChainedBuffer()`.
- explicity note `PacketBuffer::Next_ForNow()` remaining use in TLV.
- make `PacketBuffer::Free()` private.
- make `PacketBuffer::Consume()` private.
- make `PacketBuffer::AddToEnd_ForNow()` private (still used in tests).
- remove `PacketBuffer::FreeHead_ForNow()`.
- remove `operator*`.

Part of issue #2707 - Figure out a way to express PacketBuffer ownership in the type system

* Fix build (crossed paths with #4132)

* Remove PacketBufferHandle::Free()

* Fixes for #4241
@andy31415 andy31415 deleted the 01_chip_mdns_operational branch October 28, 2021 14:02
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.

6 participants