-
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
chip-device-ctrl: do not hardcode UDP listen port #9309
Conversation
Size increase report for "esp32-example-build" from 51c9327
Full report output
|
What happens with a zero as parameter then, it s dynamically choose a port to listen to..? |
Yes, zero means use any (dynamic) port. This is a standard Unix convention. |
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 OK as far as it goes, but only because we never end up resolving the controller's mdns advertisement so far. If we did, it would break, because the mdns advertisement always advertises CHIP_PORT
.
Of course that was broken before this change too....
Problem
chip-device-ctrl hardcodes the UDP listen port to CHIP_PORT+1. This makes it impossible to have more than one instance of the python controller on the same host. The target device is unable to tell which one is which and messages arrive to both which results in communication failure.
Change overview
Do not hardcode the UDP listen port.
Testing
How was this tested? (at least one bullet point required)
Notes
A similar fix can be applied to chip-tool but that hasn't been tested yet so it is not included here.