TallyArbiter port allocation

[syoffe]

Hello,

First of all, I have just stumbled across this amazing project - thank you so much for releasing this open source!

In order to set up my tally light, I need to port forward the traffic. The server uses port 4455 but the connecting devices appear to use a "random" port. I was wondering if it is possible to set or at least restrict the port range? Basically, my tally light is on another subnet, so I need the device in the middle to pass the packets on. An IP route entry is not an option in this particular configuration.

Thanks for any advice,
Sam

[hrueger]

Hi, what do you mean by "connecting devices"?

[JTF4]

Ahhhhh. I believe that you are running into one of the funny things about the TCP protocol.

The server will communicate on port 4455, but when the client initiates contact, it doesn't necessarily use the same port.

You don't have to forward the port that the listener client is connecting with, as it's not behind your firewall.

[syoffe]

Ah OK, please excuse what is probably a trivial question (I'm pretty new to networking). If the listener knows how to route to the server and initiates the connection (by registering as a listener), then does the server always know how to route to the listener? Even if the server doesn't have a route to the listener (i.e. it can't ping it)?

[syoffe]

Just to check my understanding:
listener:51xxx |--- (subnet 1) ---> bridge device --- (subnet 2) ---> server:4455
On the bridge device I do not need to port forward 51xxx to the listener? Packets from the server will know how to hop the bridge and route to the listener without my intervention?

[syoffe]

Just to say thank you - you are quite right, TCP witchcraft seems to take care of it!

[JTF4]

Just to check my understanding:
listener:51xxx |--- (subnet 1) ---> bridge device --- (subnet 2) ---> server:4455
On the bridge device I do not need to port forward 51xxx to the listener? Packets from the server will know how to hop the bridge and route to the listener without my intervention?

Yes. This is correct. You don't need to port forward to the listener because the magic behind the tcp protocol handles it.