Script for setting up linux namespaces

[cecille]

This will let developers run a controller and device on the same
machines.

Problem

We don't have an very easy way to run device and controller on the same machine.

Change overview

Adds a script to allow running device and controller on the same linux machine using namespaces.

Testing

Tested manually using the lighting app and chip-device-ctrl. With ipv4 support, can ping both ways across the namespace in ipv4 and ipv6.

[bzbarsky-apple]

Looks reasonable as a general thing; I don't have the background to have verified the details of the script so far. Can read up on this and do that if needed.

[woody-apple]

@cecille please restyle:)

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[msandstedt]

For my edification, is this only needed because all instances of the sdk bind to port 11097? That's a limitation of the sdk, not the spec.

I'm not saying this script isn't needed. I just want to understand why it's needed.

[cecille]

Sorry all - I went to go work on some TE3 stuff and let this PR stagnate a bit. It's basically just a helper script for doing controller <-> device development on the same workstation. Being able to compile and test on a linux workstation is just faster than the pi. So you can run the device side using the script and the controller on the same machine. It's not intended as a full test system currently (because it still requires root access).

[woody-apple]

/rebase

[msandstedt]

Sorry all - I went to go work on some TE3 stuff and let this PR stagnate a bit. It's basically just a helper script for doing controller <-> device development on the same workstation. Being able to compile and test on a linux workstation is just faster than the pi. So you can run the device side using the script and the controller on the same machine. It's not intended as a full test system currently (because it still requires root access).

I understand why this is useful. But do you know specifically what limitations we have in the sdk that force us to create such a solution? It would be good to know because these limitations do not arise from the spec. These are limitations of our implementation choices in the sdk.

If we could know these limitations, we could probably address them so that the sdk could support this type of operation out of the box. Is this really just as simple as the fact everybody is binding to the same port 11097? If so, I think this will be easily addressed once mDNS is ubiquitous in the stack and fully supported.

[woody-apple]

/rebase

[cecille]

Mdns would still throw a wrench in the works though, right? it's all 5353

[msandstedt]

Mdns would still throw a wrench in the works though, right? it's all 5353

All of the instances should be able to advertise by talking to avahi-daemon.

[cecille]

That would mean that no one could use the minimal mdns implementation for testing, but maybe that's not a deal breaker.

Honestly, I don't care enough about this to fight to have it go in. I have a local copy that I can use. @msandstedt If you can put up a PR to allow port changes and maybe instructions on how to do device -> controller on the same computer, I can abandon this PR.

[msandstedt]

That would mean that no one could use the minimal mdns implementation for testing, but maybe that's not a deal breaker.

Honestly, I don't care enough about this to fight to have it go in. I have a local copy that I can use. @msandstedt If you can put up a PR to allow port changes and maybe instructions on how to do device -> controller on the same computer, I can abandon this PR.

I'm not at all claiming we shouldn't have the tool provided by this PR. I think it's great and I think we should have it. That's why I approved some time ago.

I'm just using this as a vehicle for us to discuss why we would need such a tool. I think it's good for us to understand this so that we don't inadvertently introduce constraints into the sdk that really shouldn't exist. Based on the discussion, I expect (in the absence of such a tool) the constraints for Matter nodes operating within a single network stack are at least the following:

• require a single, aggregating advertiser (e.g. avahi-daemon) for mDNS
• cannot share ports for other services
• only one node can be a member of any given Matter multicast group
• there are likely other implicitly shared bits of state (e.g. within BLE transceivers)