-
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
Make the Python controller listen on CHIP_PORT + 1 like all our other controllers #7800
Make the Python controller listen on CHIP_PORT + 1 like all our other controllers #7800
Conversation
… controllers. This way if both chip-device-ctrl and a server app are running on the same IP they don't stomp on each other's ports.
64c13d8
to
965a125
Compare
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.
Instead of hard code a port number, can we add a parameter to python script for the port number and set it to CHIP_PORT + 1
by default?
Note that as long as chip-device-ctrl hardcodes the port to any number it will never be possible to connect to more than one server on the same IP. The full solution is to specify the port number like chip-tool does. The change here only fixes the 1 client + 1 server on the same IP case. A backwards compatible syntax for specifying the port would be: |
Yes, we could. I filed #7822 on this.
There are two port numbers: the port the controller runs on and the port the server runs on. chip-tool hardcodes (mostly; you can prep the PersistentStorage with a different value, I guess) the former, afaict, and allows controlling the latter via command-line arg. I agree that |
… controllers. (project-chip#7800) This way if both chip-device-ctrl and a server app are running on the same IP they don't stomp on each other's ports.
This way if both chip-device-ctrl and a server app are running on the
same IP they don't stomp on each other's ports.
Problem
Running chip-device-ctrl against an all-clusters-app on the same machine fails due to them both listening on the same port
Change overview
Use CHIP_PORT+1 for the listen port in the controller, like our other controllers.
Testing
Made sure that:
connect -ble
to an m5stack running all-clusters-appconnect -ip 127.0.0.1
against an all-clusters-app running on the same machine the responses from all-clusters-app make it to the Python controller instead of being received by all-clusters-app itself (which is what happened before this change, because the controller was claiming to be sending from CHIP_PORT.