Bugzilla – Bug 8800
Problem communicating across networks using SSH tunnel
Last modified: 2012-03-22 11:30:23 UTC
A customer wanted me to file this enhancement request for him. Here is his description of it: the "enhancement" I'd like to have is that, when I add a "Music Source" manually by giving its IP address, from the duet, it does not try to do (and does not require to) have access to port UDP3483 on this IP address (at least this UDP3483 access is what I've observed using packet sniffer - wireshark - and as soon I've open this access adding the new source became available, although I've also noticed that this UDP3483 access is _never_ required later, only at initial configuration. The use case is to be able to have access over an SSH tunnel, which does not work if any UDP port is required as SSH does not forward UDP, only TCP.
I'm a little confused by this description. Is he saying that he can't connect to a server outside his local subnet even by entering the IP address?
Yeah, I'm not clear either on what problem the original bug report is intended to solve. (I'm just following this bug because I have a general interest in using the SBC for and SSH tunnel...)
*** Bug 9879 has been marked as a duplicate of this bug. ***
Well, I'm not entirely sure that bug 9879 is a full duplicate of this one because it was for SqueezePlay. But to add a bit more detail to this one: Situation is that a computer at work running SqueezePlay currently cannot connect to a home server through a SSH connection to play the person's music. Using SqueezeSlave you can, by the way. My understanding (second hand so may not be fully correct/complete) is that one or more of the ports isn't forwarding properly through the SSH client/server. I believe that it is the UDP one(s) - as originally stated in this bug. Not sure if this is in scope for this or not, but just in case: It would also be nice to be able to specify a name for the "remote server" instead of just an ip address. My work, at least, uses dynamic IP addresses and I'd like to, at some point, bring in one of my Squeeze* devices (like the Squeeze Radio) and have it connect to my home server and I'd think that it would have to do that by specifying the address of my work computer (which would potentially be changing) for the SSH forwarding. If it could connect without having to have the computer doing the SSH client then even better, but I'm sure that would be outside the scope of this.
Yeah, just to elaborate on what Doug said -- this is a real problem with SqueezePlay in what I thought was its intended use. As a replacement for SoftSqueeze, I thought the main use of SqueezePlay was supposed to be accessing your music from your SBS when away. If so, SqueezePlay shouldn't require any UDP ports to be forwarded, so that it can work with an SSH client, which is undoubtedly the most secure way to connect to SBS when away. SoftSqueeze, of course, has a built-in SSH client, which is nice and would be a nice future addition to SqueezePlay, but the more pressing issue is just to get SqueezePlay to work when an SSH tunnel is already established. Until this is fixed SqueezePlay will never replace SoftSqueeze.
Andy notes that the real bug is that entering an IP address for the server doesn't work unless you're on the same segment. This may be something related to IP and UDP ports both needing to communicate.
7.4.x milestone is in the past
Tom is no longer available to us
As described here: http://forums.slimdevices.com/showthread.php?t=81053 I can't get my touch to communicate with my server over a SSH tunnel. I take it this is the same problem described in this bug, as the Touch uses SqueezePlay? If so, this is ridiculous -- this bug is over 2 years old! SSH is the most sensible way to remotely access SB Server; there's really no way to get the newest Squeezebox products to work with this?
Per Question Reference No 100814-001939 just submitted to Logitech tech support, because no one seems to have any interest in fixing this bug, I'd like to return my Touch to Logitech for a refund. I'm well past my return window, but the Touch hasn't been used -- I bought it to use at a remote location where, because of this bug, it cannot be used, though all of my other Sqeezeboxes (several Booms and a Classic) work just fine there. If someone could help me arrange for this return I'd appreciate it.
So I have returned by Touch b/c of this issue. I understand you folks are busy, but really, could someone provide some kind of response on this? If you never intend to get SqueezePlay and players based on it working over SSH, can you at least say so?
Please, please, PLEASE, (pretty P-L-E-A-S-E) fix this issue so that SqueezePlay will work over a SSH tunnel. As a previous comment points out, this ticket is two years old, and it seems ridiculous that something that previously worked with SoftSqueeze still doesn't work with SqueezePlay. Especially considering that a large percentage of SqueezePlay's use cases probably require (or would benefit from) a SSH tunnel, this should be a high priority issue for SqueezePlay.
Good luck. No one's listening. Logitech was actually nice enough to give me a refund for my Touch after I'd had it for several months b/c of this issue, but their willingness to give the refund suggests that this isn't going to be fixed any time soon.
It's really sad this doesn't get fixed, especially as it is now possible to establish the ssh-tunnel on the squeezebox itself, only squeezeplay cant't make use of it due to this unnecessary need for UPD :-(
Yes, the lack of these feature/fix is essentially what doesn't allow me to show off the entire squeezebox line as much as I'd like to. I can't take it to work or anywhere else. I know lots of people that appreciate high quality sound but require portability so they use stripped down mp3 and ipod-type players instead of what they'd really like to have.
Over 3 years old. If someone fixes this (allowing SqueezePlay and SqueezePlay players to work over an SSH tunnel) I will pay them $1000. Contact me if you're interested.
Unassigned bugs cannot have a priority.
I was able to workaround the UDP requirement and have posted my findings at http://stonezdup.com/2012/03/ssh-tunneling-with-squeezebox-and-squeezeplay/ The main trick is using socat (http://www.dest-unreach.org/socat/) to forward the UDP traffic over a random SSH forwarded port and then retranslates it back to to UDP on the other side. There's a lot more information in the blog post, but I wanted to include a straightforward shell script here just in case something happened to my server. #!/bin/bash username=example_user hostname=example.com ssh -f -g \ -L 3483:localhost:3483 \ -L 3484:localhost:3484 \ -L 9000:localhost:9000 \ $username@$hostname \ 'socat tcp4-listen:3484,reuseaddr,fork UDP:localhost:3483' socat -T15 udp4-recvfrom:3483,reuseaddr,fork tcp:localhost:3484