Random unexpected port after walk_to

[bacox]

When I use a manual introduction between two communities using walk_to, on rare occasions it uses a random port for the connection.
Around 5% of the runs have this behavior.

Description

For community A the host and port are set to 192.168.55.10:9090.
For community B the host and port are set to 192.168.55.11:9091.

The communities run in separate docker containers.

When using a manual walk_to(192.168.55.11,42:9091) the connection can end up like ('192.168.55.11', 51061) when I call get_peers(). In normal occasions, the host and port looks like ('192.168.55.11', 9091).

Output

Currently I do not have a traceback of an error because no error is thrown.
The output in my application is as follows:

node1-1  | [Node 1] Starting with delay 3 and connections: [(0, 9090)]
node0-1  | [Node 0] Starting with delay 0 and connections: [(1, 9091)]
node0-1  | [Node 0] Walking to ('192.168.55.11', 9091)
node1-1  | [Node 1] Walking to ('192.168.55.10', 9090)
node1-1  | [Node 1] send introduction to Peer: Peer<192.168.55.10:9090, B8jTPERrIo5JsfYPRoamo0XahlM=>
node0-1  | [Node 0] self.get_peers()=[('192.168.55.11', 59638)]
node1-1  | [Node 1] Starting
node1-1  | [Node 1] self.get_peers()=[('192.168.55.10', 9090)]
node0-1  | [Node 0] Walking to ('192.168.55.11', 9091)
node0-1  | [Node 0] self.get_peers()=[('192.168.55.11', 59638)]
node0-1  | [Node 0] Walking to ('192.168.55.11', 9091)
node0-1  | [Node 0] self.get_peers()=[('192.168.55.11', 59638)]

Is there an explanation why some connections end up with a random port instead of the port that is creates the community with?

[qstokkink]

There is certainly a reason. Long story short, this is by design: it is occurring because IPv8 is continuously trying to be smart about the ports it uses to more effectively traverse your network address translation. This is also why the big warning block is in our "Creating your first overlay" documentation: never, ever, depend on the (IP, port) of a peer.

You can get a more complete overview from https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/ford/ford.pdf (if you're interested).

[bacox]

Although a port change can happen and is expected behavior, communication breaks down after this. The UDPv4Address and the UDPv4LANAddress are different after the port change. Only when I force IPV8 to ignore the port change and continue with the original ports communication resumes.
This last part doesn't sound like expected behavior.

[qstokkink]

Indeed. I'll put this on the roadmap.

[qstokkink]

I looked through the IPv8 internals and analyzed the different address updates. The only thing that makes sense to me would be that this is a faulty remap in whatever address translation is being used. I don't think we can do anything about this root cause within IPv8. However, we can mitigate this behavior for experiment setups.

What we can do is add functionality to Peers to make their addresses "read-only", ignoring the sender address reported by the Operating System. This would allow you to set up an experiment for well-known (IP, port) tuples. @bacox would that work for you?