View Full Version : Using TCP with the Controller

2008-07-03, 14:10
Hi - I want a duet to use my squeezecenter server from a remote location. This is working fine by opening ports 9000 and 3483 in my router, but I don't like having open ports like this.
Basically I always access my network through SSH.
Unfortunately, it seems that the controller is using UDP to access the server and of course, as SSH cannot tunnel UDP, this does not work .
I'm surprised because I thought that now the slim protocol was TCP-based (since version 5 or something like that).
I've checked my configuration with SoftSqueeze which implements the TCP version, and everything is running fine, I'm able to access my home server using a SSH tunnel with PUTTY on the client.(I don't use the built-in SSH in SoftSqueeze because my SSH server @ home is not running on the same machine than the squeezecenter server and doing additional port forwarding on my SSH server + gatewayports is not convenient).
Any idea how to force the controller to use the TCP version of the protocol ?


PS : I'd like to avoid doing the complicated UDP->TCP->UDP bridge to "mascarade" UDP forwarding on the client, so this is not my preferred option

2008-07-03, 16:19
What UDP traffic are you seeing? I was under the impression UDP was only used for the discovery protocol, which is optional.

2008-07-03, 20:11
I saw this using ethereal when I was trying to analyze what was going wrong. You might be very right that it is just used for discovery, the problem is that I even cannot pass this stage because once I did enter the IP address of my PuTTY client as the squeezecenter ID, the first thing the controller does is "probing" it using UDP and as it does not work, it will not go beyond

2008-07-03, 21:19
As radish says you shouldn't need UDP. It will try to discover servers
using UDP, but if you define the server manually in the music source menu,
you should be fine without.


2008-07-04, 05:52
This is what I've done : setting the IP address of the server in the "Music Source" option of the menu. But it seems that the controller insist on starting with a first UDP packet to this IP address and will not proceed until he gets a response - see the log attached below (the .100 is the controler and the .109 is my gateway, running PuTTY). It will go on and on like this foreever.
BTW, as a proof that this setup is good, everything works fine when using Softsqueeze from another computer on my network (not the same one running PuTTY)

2008-07-05, 05:15
I've found the reason and a workaround to my problems

- The controler will always use UDP3483 when required to access a new SqueezeCenter, even if the IP address of the squeeze center is manually enterer
- But it requires to do this only once, I guess for getting some parameters. Once it is done, no need for UDP3483 anymore (even after reset)
- So, on my remote location, I have a "gateway" computer running PuTTY to create the tunnel with my squeezecenter at home. PuTTY on this gateway create the tunnel for TCP9000 and TCP3483, it also enables other computers to use theses ports (ie this gateways "looks like" the real squeezecenter, but it is only a conduit in fact)
- I opened temporary UDP3483 on my router at home and forward it to my real squeeze center. On the gateway computer, I used a port forwarder (eg NetworkActiveAUTAPF) which forward UDP3483 to my home squeezecenter
- The squeezecenter IP address given to the controller is the gateway's one and once it has done the initial "exchange", I just close the UDP3483 port on my home router and close NetworkActiveAUTAPF
- Then, only the SSH tunnel forwarded ports are needed, I've tried couple of hours and did some reset in between to see if the configuration was retained, and it seems to work