Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Ah that's a shame the process is still a bit brittle. > > Are you certain there was no SP process running prior to kicking off the > socats and ssh? In my case, if that was so, I also experienced the kinds > of wrinkles you described. The issue is with the "fork" option on socat > - if it's running and there's application traffic on that UDP port being > generated by SP, it can fork off many child processes to handle it. So > if there is UDP traffic there may be a race condition with the "killall > socat" killing off the parent process but leaving one or more children, > or vice versa. For more insight killall also provides a "-v" option > which describes what processes it's killing more verbosely. If SP is not > running there should be no UDP traffic on 3483 and the killall socat > should work as intended. > > By using the shell "cmd1 && cmd2" operator, this should absolutely > ensure that cmd2 is not invoked before cmd1 terminates, and moreover, > terminates successfully. Alternatively you can use "cmd1; cmd2" for > serial execution of 2 commands on a single line - in that case cmd2 > always runs after cmd1 irrespective of the exit status of cmd1. So I > don't think the issue is the killall not completing before with socat is > launched. > > I have not tested putting shell operators like "&&" or "&" into the > RemoteCommand line in ~/.ssh/config. But it would not surprise me if > these don't work as intended. It would all come down to the exact way > ssh forks off the remote shell and passes the command + arguments to it. > I would recommended that if you need to use "&&" or "&" operators, it's > best to put everything into a single shell script file and just launch > that from the RemoteCommand directive (which is what I think you ended > up doing). Make sure you specify the full path to your shell script on > the remote machine to avoid issues with the PATH variable. > > It would not hurt to put a killall socat into the remote command script. > If you are doing it on one line, make sure you use "&&" or ";" (not > "&") to separate the killall and the socat. Of course, if you place > these commands on separate lines, this would also ensure the commands > are executed sequentiually rather than in parallel. In my case however, > I found that in 100% of the cases when I killed the ssh session with > Ctrl-C, it always killed off the remote socat(s) as well. So I found I > didn't need that remote "killall socat". But again, depending on the OS > and versions of SSH used etc., it wouldn't surprise me if in some cases > the remote socat is left running in the background and should be killed > off explicitly. > > Sometimes it's better to go with simpler solutions to these things > rather than trying to come up with clever 1-liners :) Indeed - thanks. However, it took me 30 seconds to work out what SP meant - I'm not good with abbreviations I've never seen before ;) LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > Yes, but it took me most of an evening to discover little wrinkles. I > went round many, many possibilities and variations before making it > stable. > > I had produced a script to run it all, starting with "killall socat && > soc", and quite often it failed. I think what was happening was > that the killall didn't complete before the socat got up and running, so > killed it. Putting the killall on one line and socat on the next seemed > to fix it. Strange. > > I had also added a "killall socat &&" to the Remote command line in the > .ssh config. That similarly caused random havoc, so had to go. Ah that's a shame the process is still a bit brittle. Are you certain there was no SP process running prior to kicking off the socats and ssh? In my case, if that was so, I also experienced the kinds of wrinkles you described. The issue is with the "fork" option on socat - if it's running and there's application traffic on that UDP port being generated by SP, it forks off a child process to handle it. So there may be a race condition with the "killall socat" killing off the parent process but leaving a child, or vice versa. For more insight killall also provides a "-v" option which describes what processes it's killing more verbosely. By using the shell "cmd1 && cmd2" operator, this should absolutely ensure that cmd2 is not invoked before cmd1 terminates, and moreover, terminates successfully. Alternatively you can use "cmd1; cmd2" for serial execution of 2 commands on a single line - in that case cmd2 always runs after cmd1 irrespective of the exit status of cmd1. So I don't think the issue is the killall not completing before with socat is launched. I have not tested putting shell operators like "&&" or "&" into the RemoteCommand line in ~/.ssh/config. But it would not surprise me if these don't work as intended. It would all come down to the exact way ssh forks off the remote shell and passes the command + arguments to it. I would recommended that if you need to use "&&" or "&" operators, it's best to put everything into a single shell script file and just launch that from the RemoteCommand directive (which is what I think you ended up doing). Make you you specify the full path to your shell script on the remote machine. It would not hurt to put a killall socat into the remote command script. If you are doing it on one line, make sure you use "&&" or ";" (not "&") to separate the killall and the socat. Of course, if you place these commands on separate lines, this would also ensure the commands are executed sequentiually rather than in parallel. In my case however, I found that in 100% of the cases when I killed the ssh session with Ctrl-C, it always killed off the remote socat(s) as well. So I found I didn't need that remote "killall socat". But again, depending on the OS and versions of SSH used etc., it wouldn't surprise me if in some cases the remote socat is left running in the background and should be killed off explicitly. Sometimes it's better to go with simpler solutions to these things rather than trying to come up with clever 1-liners :) nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > You would think so! I tried as you suggested right at the start, setting > the remote library IP address explicitly. However, SP still wanted to do > it's server discovery thing every time it started, and it would not drop > into the normal UI no matter how many times the discovery failed. It > would just keep asking to either try connecting again or specify a > different library. > > It seems that even with an explicit remote library configured, SP still > wants to complete a server discovery process and "find" at least one > server before presenting the main UI. Probably it's an oversight. If one > or more remote servers have been explicitly configured, it should just > skip the discovery process. Same here. There was no way I could persuade it just to take the ip rather than trying to discover first, even though it had run with that ip previously. LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Hopefully it works for you too. Yes, but it took me most of an evening to discover little wrinkles. I went round many, many possibilities and variations before making it stable. I had produced a script to run it all, starting with "killall socat && soc", and quite often it failed. I think what was happening was that the killall didn't complete before the socat got up and running, so killed it. Putting the killall on one line and socat on the next seemed to fix it. Strange. I had also added a "killall socat &&" to the Remote command line in the .ssh config. That similarly caused random havoc, so had to go. LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > Thanks very much for the details. I'll adjust my settings similarly. Hopefully it works for you too. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
Thanks very much for the details. I'll adjust my settings similarly. LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
Thanks for this summary! Quick Q (and this one probably comes really late...): Wouldn't SP have worked with TCP connections alone if you configured it to connect to a specific IP address (Settings/Advanced/Network/Remote)? Server discovery would not have worked, but that wouldn't hurt, would it? -- Michael ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
For the record, here's the configuration that finally worked for me. My Environment: - SqueezePlay machine: MacBook Pro, OSX El Capitan (10.11.6) - LMS machine: MacMini, OSX El Capitan (10.11.2) - LMS is configured on port 9500 Prerequisites: - You need to have ssh installed and be able to ssh into the LMS machine from your SqueezePlay machine - You need to have socat installed on both machines. I installed socat on OS X with Homebrew SSH Configuration: I prefer to put all my ssh options into the ssh config file ~/.ssh/config so I don't need to specify them on the command line. Here is the entry for the ssh tunnel: Code: Host lms-tunnel Hostname xxx Port xxx User xxx ForwardX11 no RequestTTY no LocalForward 9500 localhost:9500 LocalForward 3483 localhost:3483 LocalForward 34831 localhost:34831 Note 1: Customize the Hostname, Port & User "xxx" strings with your specific values. Note 2: Because my LMS is on port 9500, "9500 is used in the first LocalForward statement. For vanilla LMS installations, use "9000" in both places instead. Individual commands: On SqueezePlay machine: Code: ssh -v lms-tunnel socat -v -t3600 -T3600 udp-listen:3483,reuseaddr,fork tcp:localhost:34831 On LMS machine: Code: socat -v -t3600 -T3600 tcp-listen:34831,reuseaddr,fork udp-sendto:localhost:3483 Note: the -v options on socat and ssh are optional. They just enable verbose logging which helps troubleshooting if needed. Putting it all together: If you wish, you can streamline the execution of the above 3 commands as follows: First, modify the ssh configuration to be as follows: Code: Host lms-tunnel Hostname xxx Port xxx User xxx ForwardX11 no RequestTTY force LocalForward 9500 localhost:9500 LocalForward 3483 localhost:3483 LocalForward 34831 localhost:34831 RemoteCommand /full/path/to/your/socat -t3600 -T3600 tcp-listen:34831,reuseaddr,fork udp-sendto:localhost:3483 Note: Replace /full/path/to/your/socat with the actual path of socat on the LMS machine, eg /usr/local/bin/socat Now, to run all 3 commands together, copy/paste the following shell statement into a Terminal window on the SqueezePlay machine: Code: killall socat && socat -t3600 -T3600 udp-listen:3483,reuseaddr,fork tcp:localhost:34831 & ssh lms-tunnel Note 1: Ensure SqueezePlay is not running prior to running this command! Note 2: The ssh command will run in the foreground and block for the duration you need the tunnel up. This makes it easy to break down (just type Ctrl-C to kill it, and optionally killall socat to clean up the socat which runs in the background). Note 3: The -v options have been left out in this example. Finally launch SqueezePlay. It should see the name of your remote LMS and connect to it successfully. If you have LMS password protection enabled SqueezePlay will prompt you to enter the credentials. Enjoy using SqueezePlay to connect to your remote LMS via ssh & socat! nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Well I couldn't leave it :) > > I did some more research and found the correct spell for socat. On the > local Player side, invoke socat with "udp-listen:3483" instead of > "udp-recvfrom:3483". This will modify socat's behaviour to create 1 > long-lived TCP connection instead of 1 per UDP datagram. And in my case > the -t3600 is still required (because of my network latency). > > With this in place, SqueezePlay is finally working!! :) > > I will write up a final summary of my working configuration and add it > to this thread in a little while. > > Thanks to all for their suggestions and ideas. Congratulations! I wouldn't have been able to analyse the traffic in the way you have done. LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > socat is quite a complex utility and there may be further options > available to fine-tune how the UDP/TCP bridging works to solve these > issues Well I couldn't leave it :) I did some more research and found the correct spell for socat. On the local Player side, invoke socat with "udp-listen:3483" instead of "udp-recvfrom:3483". This will modify socat's behaviour to create 1 long-lived TCP connection instead of 1 per UDP datagram. And in my case the -t3600 is still required (because of my network latency). With this in place, SqueezePlay is finally working!! :) I will write up a final summary of my working configuration and add it to this thread in a little while. Thanks to all for their suggestions and ideas. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > If it asked you for an LMS username and password that's beyond where I > got to, since I don't use a LMS password, and might well need other > ports etc. Or are you referring to a normal linux user password? No, I was referring to the LMS username/password you set in Settings > Advanced > Security > Password Protection. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > Do you expect an user name/password exchange with LMS? If so, surely > that's another set of messages, possibly needing more/different socats? Hi, to clarify, this is the LMS username/password feature. SqueezePlay does appear to understand this protocol and captures both credentials in its UI, as part of connecting to a remote server. I think we are OK with that part of the puzzle. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
I have made progress but it's still not working :( The heart of the issue seems to be the subtlety in bridging UDP network traffic, which is by definition unidirectional, stateless and connectionless, over a TCP channel, which is the opposite: bidirectional, stateful and connection-based. What we want to achieve with socat is firstly to establish a single, permanent, long-living, bidirectional TCP tunnel using port 34831. Then, we want to leverage the udp-recvfrom / udp-sendto bits to capture the UDP datagrams in either direction and transmit them to the other side through the tunnel. I don't think this has been achieved with my versions of socat, OS, etc. and the options used. Prior, I reported that the replies from LMS to the Player were not going back through the tunnel. I found the reason for that was, due to the unusually lengthy network latency between my LMS and Player, the local socat was -closing- the TCP socket before the response arrived back from the remote side. Connection longevity seems to be controlled by the "-t" parameter (lowercase) and by default it's 0.5 seconds. By adding a "-t3600" to my local socat, I finally was able to see the replies from LMS getting back to the Player. If the network latency between a Player and remote LMS was under 500ms this issue may not occur. So with that in place, I progressed a bit. Now when I start the Player, it does its discovery and discovers 2 servers, 127.0.0.1 and MacMini2. The latter is the name of my LMS and was found due to the discovery process now working. Attempting to connect to these took me to the Username/Password dialog, again which was very promising. However, after entering the credentials I am again stuck with the Player reporting it is not able to connect to the server (either 127.0.0.1 or MacMini2). What I see a lot of is that every time the Player emits a UDP packet, a new TCP connection request is logged by ssh. This results in hundreds of open TCP connections, which is not a good thing. When I kill off the socats ssh reports closing all these connections, but it shouldn't be like this. We should only be creating 1 long lived TCP connection, keeping it alive so that it may transfer UDP datagrams whenever they are emitted. What I do see is continuous chatter on the UDP channel, the same request being emitted over and over again by SqueezePlay. And responses from LMS arriving much later. Probably, this is due to a retry mechanism built into SqueezePlay. With UDP, there is no built-in retry mechanism like TCP, delivery of each datagram is "best effort" only, and all retry logic must be done in the app itself. Because UDP is a fast and light connectionless protocol, designed to work best over local area networks, it's likely we are seeing a timeout issue where if the Player does not get a response to its first UDP message in a certain very short period it retries and sends another. This cascades - it may send 5 or 6 requests out before the first reply comes back over ssh/socat. This is what the logging data suggests is going on in my case. As to why, after the discovery handshake succeeds, the Player still cannot connect to LMS is a mystery. socat is quite a complex utility and there may be further options available to fine-tune how the UDP/TCP bridging works to solve these issues. For now, I'm going to have to leave it. Thanks. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > If it asked you for an LMS username and password that's beyond where I > got to, since I don't use a LMS password, and might well need other > ports etc. Or are you referring to a normal linux user password? Do you expect an user name/password exchange with LMS? If so, surely that's another set of messages, possibly needing more/different socats? LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > In my case I definitely didn't need any more socats. If I get time I'll > run tests again to make sure nothing has changed. I think you're right. The plot thickens. The socat documentation talks about symmetric linkage. For example, if we use a "udp-sendto" on one side and a "udp-recvfrom" on the other, socat will automatically relay reply packets to/from the UDP ports where data was transmitted from server to client. Hence, we don't need the extra pair of socats after all. However, armed with this knowledge, still can't get it to work. I tried changing Code: socat tcp4-listen:34831,reuseaddr,fork UDP:localhost:3483 to Code: socat tcp4-listen:34831,reuseaddr,fork UDP-SENDTO:localhost:3483 to make it symmetric with the UDP-RECVFROM. But that isn't working either. I have a feeling it's the response from LMS that is not making back to the Player. In the socat window running on the LMS server, I see a healthy dialog: Code: > 2018/10/16 23:55:11.810076 length=37 from=0 to=36 eIPAD.NAME.JSON.VERS.UUID.JVID..4Vx.4 < 2018/10/16 23:55:11.810751 length=74 from=0 to=73 ENAME\bMacMini2JSON.9500VERS.7.9.0UUID$75ab0441-2381-4093-a814-0fc6f05ede7b This is confirming the socat sees a 37-byte incoming message on TCP 34831 (from the Player), and confirms a 74-byte response is received from LMS and relayed back. And if you look in the response you will see the name of my LMS server (MacMini2) and the port (9500) and the LMS version number (7.9.0). So this is as expected. It's just somehow the response is not making it back through ssh to the Player LAN. I will continue investigating why. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Could be getting warm here. By what means does the Player get the > response(s) from the LMS(s) ? > > If that is also occurring over UDP, then we need to set up another pair > of socats to complete a fully symmetric UDP bridge (ie, UDP datagrams > transmitted by the Player on the local LAN get relayed to the remote > server's LAN with one pair of socats, and UDP datagrams transmitted by > LMS on the remote LAN are relayed to the local LAN so they can be > received by the Player). As it stands now, we are only relaying UDP > packets from the Player to the LMS. I believe we would need to kick off > 2 more, as follows: > > On player LAN: > > Code: > > socat tcp4-listen:34831,reuseaddr,fork UDP:localhost:3483 > > > > On LMS LAN: > > Code: > > socat -v -T3600 udp4-recvfrom:3483,reuseaddr,fork tcp:localhost:34831 > > > > Well, I will try this and report back. In my case I definitely didn't need any more socats. If I get time I'll run tests again to make sure nothing has changed. LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Just tried that, and SqueezePlay doesn't have a problem with LMS > password. It connected to my local LMS immediately and prompted me to > enter a username/password, after which I had full access to my library. > OK, so we can rule that one out. > > Thanks. If it asked you for an LMS username and password that's beyond where I got to, since I don't use a LMS password, and might well need other ports etc. Or are you referring to a normal linux user password? LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > We don't need discovery, because we have explicitly specified a Remote > Library with the IP address of the LMS (127.0.0.1), and ensuring TCP > ports 9000 and 3483 are relayed. SqueezePlay should "believe" these > settings and just connect to LMS. Why does it need to go through the UDP > discovery process when we have defined the LMS IP address? Not sure. My guess is that some userd have both local LMSs and a remote LMS and discovery only happens once at Player startup. If the users wants to change from Remote to local - there is no need to reconfigure and cycle power. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
bpa wrote: > All LMS servers who "hear" the broadcast will respond - this way player > is told of all available LMS servers and IP address - user can then pick > on player which LMS to connect. Could be getting warm here. By what means does the Player get the response(s) from the LMS(s) ? If that is also occurring over UDP, then we need to set up another pair of socats to complete a fully symmetric UDP bridge (ie, UDP datagrams transmitted by the Player on the local LAN get relayed to the remote server's LAN with one pair of socats, and UDP datagrams transmitted by LMS on the remote LAN are relayed to the local LAN so they can be received by the Player). As it stands now, we are only relaying UDP packets from the Player to the LMS. I believe we would need to kick off 2 more, as follows: On player LAN: Code: socat tcp4-listen:34831,reuseaddr,fork UDP:localhost:3483 On LMS LAN: Code: socat -v -T3600 udp4-recvfrom:3483,reuseaddr,fork tcp:localhost:34831 Well, I will try this and report back. > If player is not on same segment as LMS then LMS will not hear the > broadcast. I think in our situation this isn't the case, based on verbose output I'm seeing from ssh and the socats. As soon as SqueezePlay starts, I see activity that the local socat has seen a UDP packet on 3483 and has relayed it to TCP 34831; immediately ssh reports seeing data on TCP 34831 and relays that to the remote server side; and finally the remote socat reports seeing data on TCP 34831 and relays that to UDP 3483. Therefore, in the Player > LMS direction, I think things are working as expected. > Player can always choose which LMS server to use (even if not on same > LAn segment) by defining the LMS IP address. That's why this discovery protocol seems strange to me in this case. We don't need discovery, because we have explicitly specified a Remote Library with the IP address of the LMS (127.0.0.1), and ensuring TCP ports 9000 and 3483 are relayed. SqueezePlay should "believe" these settings and just connect to LMS. Why does it need to go through the UDP discovery process when we have defined the LMS IP address? Anyway... probably should just run Wireshark on the LMS LAN and capture the entire network dialog between SqueezePlay and LMS on every port :) Thanks. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Thanks. I double checked and mine are the same. It's interesting this is > working for you. As I mentioned, I wonder how the UDP broadcast part of > the protocol is working... I'll have to read up a bit more on how the > Slim UDP protocols are supposed to work. There is only use of UDP. At power up a player will broadcast a UDP packet on port 3483. All LMS servers who "hear" the broadcast will respond - this way player is told of all available LMS servers and IP address - user can then pick on player which LMS to connect. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
PasTim wrote: > I found an old report saying squeezeplay didn't like LMS with a > password. Can you run squeezeplay locally rather than remotely, just to > test it? Just tried that, and SqueezePlay doesn't have a problem with LMS password. It connected to my local LMS immediately and prompted me to enter a username/password, after which I had full access to my library. OK, so we can rule that one out. Thanks. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > Hi, thanks for those tips > Also... wonder if having password protection enabled on LMS is an issue > for SqueezePlay? > > Thanks. > I found an old report saying squeezeplay didn't like LMS with a password. Can you run squeezeplay locally rather than remotely, just to test it? LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
Hi, thanks for those tips. PasTim wrote: > Hi, > > I'm no expert at this stuff, just a slightly persistent bodger. Aren't we all. > 1. Can you log in to your LMS server with ssh remotely? Yes, this is set up and works. > 2. Is it possible to try running LMS on port 9000 instead, however > briefly? Yes, I did this, I am running LMS on port 9000 now. > 3. Are you able to get Squeezeplay to play music even if the control > side isn't working (eg using a separate laptop connected as suggested in > post #1)? Yes, this part is working. LMS can see SqueezePlay, and plays music if I control it exclusively through the LMS browser UI. SqueezePlay though, just gets stuck in a cycle of "connecting" and "try again" (see below). > 4. Can you run squeezelite instead as in post #1? I will look at that solution later. > To clarify my somewhat broken up scripts [...] Thanks. I double checked and mine are the same. It's interesting this is working for you. As I mentioned, I wonder how the UDP broadcast part of the protocol is working... I'll have to read up a bit more on how the Slim UDP protocols are supposed to work. Also... wonder if having password protection enabled on LMS is an issue for SqueezePlay? Thanks. 25796 25797 +---+ |Filename: Screen Shot 2018-10-16 at 11.59.23.png | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=25797| +---+ nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
nico wrote: > I've followed your instructions but SqueezePlay still can't connect to > my remote LMS via the assorted ssh & udp plumbing. > > I am running ssh and the 2 socats with verbose logging and I certainly > see a lot of activity from all 3 programs. When launched, SqueezePlay > displays "Connecting to 127.0.0.1" and spins for about 30 seconds, then > gives up with the message "We couldn't connect to 127.0.0.1". As > mentioned, during this time there is a lot of activity logging visible > from ssh and socat. > > Doesn't the player/server discovery protocol use UDP broadcast packets? > If so, are the socats correctly relaying those? They seem to only be > relaying unicast UDP data on 3483 in one direction from the player to > the server side. Does LMS reply back using UDP 3483, or with UDP > broadcasts? If so, we might need another 2 instances of socat to provide > the UDP backchannel... ? > > The only slight difference I can see in my configuration is that I am > running LMS on TCP port 9500 instead of 9000. Accordingly, my ssh local > forward argument for that port is > Code: > > localhost:9000:LMS-local-IP-address:9500 > > > Would that break anything? In any case I am not seeing any activity on > either ports 9500 or 9000... > > Thanks. Hi, I'm no expert at this stuff, just a slightly persistent bodger. I also haven't tried this again since earlier this year. So I've only a few comments/suggestions. 1. Can you log in to your LMS server with ssh remotely? 2. Is it possible to try running LMS on port 9000 instead, however briefly? 3. Are you able to get Squeezeplay to play music even if the control side isn't working (eg using a separate laptop connected as suggested in post #1)? 4. Can you run squeezelite instead as in post #1? To clarify my somewhat broken up scripts, the client one is: Code: # To connect via ssh, socat maps 127.0.0.1 (localhost) 3483 to 34831. Then ssh using 9000 and 3483 and 34831 to LMS. # 34831 is used to map 3483 udp to tcp and back since ssh doesn't support udp. # So run this, then connect browser or squeezeplay (etc) to localhost:9000 (or 127.0.0.1 for squeezeplay) killall socat socat -T3600 udp4-recvfrom:3483,reuseaddr,fork tcp:localhost:34831 & ssh -L 9000:LMS-ip:9000 -L 3483:LMS-ip:3483 -L 34831:lms-ip:34831 LMS-DNS /home/me/sshsocat.sh Where LMS-ip is the LMS ip address on the LMS network (eg like 192.168.1.5, or whatever), LMS-DNS is my dynamic DNS address (via mynetgear in my case), and "/home/me/sshsocat.sh" is the file location on the LMS server of sshsocat.sh, which contains: Code: killall socat socat tcp4-listen:34831,reuseaddr,fork UDP:localhost:3483 & I hope that helps. LMS 7.9.2 on VortexBox Midi box, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2 Touchs & EDO. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Also Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 18.04 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
I've followed your instructions but SqueezePlay still can't connect to my remote LMS via the assorted ssh & udp plumbing. I am running ssh and the 2 socats with verbose logging and I certainly see a lot of activity from all 3 programs. When launched, SqueezePlay displays "Connecting to 127.0.0.1" and spins for about 30 seconds, then gives up with the message "We couldn't connect to 127.0.0.1". As mentioned, during this time there is a lot of activity logging visible from ssh and socat. Doesn't the player/server discovery protocol use UDP broadcast packets? If so, are the socats correctly relaying those? They seem to only be relaying unicast UDP data on 3483 in one direction from the player to the server side. Does LMS reply back using UDP 3483, or with UDP broadcasts? If so, we might need another 2 instances of socat to provide the UDP backchannel... ? The only slight difference I can see in my configuration is that I am running LMS on TCP port 9500 instead of 9000. Accordingly, my ssh local forward argument for that port is Code: localhost:9000:LMS-local-IP-address:9500 Would that break anything? In any case I am not seeing any activity on either ports 9500 or 9000... Thanks. nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
To summarise my solution I'd just like to note that it can all be streamlined by combining the socat and ssh commands on the client side into one script, and by adding the name of the server's socat script to the end of the ssh command. I also added 'killall socat' to the two socat scripts before the socat command. So on the client side I have: Code: killall socat socat -T3600 upd4- & ssh -L ... user@LMS-dns-address name-of-server-socat-script And on the server, the "name-of-server-socat-script" contains: Code: killall socat socat tcp4- This seems to work reliably thus far. LMS 7.9.1 on VortexBox Midi box, Xubuntu 17.10, FLACs 16->24 bit, 44.1->192kbps. Touch & EDO. 2nd Touch standard. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (to A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Alternatively Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 17.10 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
ralphy wrote:
> The ssh -L feature only forwards TCP ports, so it works fine for
> squeezelite as long as you specify your lms server using -s lmshost as
> UDP is only used in the server discovery code. Squeezeplay expects UDP
> ports to be available (ie. forwarded) as well. Squeezeplay does work
> when using a vpn solution like openvpn.
>
> You may be able to get squeezeplay working with ssh by editing a couple
> of setting files as discussed in 'the thread'
> (http://forums.slimdevices.com/showthread.php?101388-Squeezeplay-won-t-connect-after-clean-install-of-Win-7-Pro/page2).
> I've had mixed success with this method.
I didn't find a solution in the lua settings files (I did try setting
ChooseMusicSource.lua to settings =
{poll={["127.0.0.1"]="127.0.0.1",},}) but I did find socat (via
http://zarb.org/~gc/html/udp-in-ssh-tunneling.html).
I added another -L for new port 34831 to my ssh command:
Code:
ssh -L localhost:9000:LMS-local-IP-address:9000 -L
localhost:3483:LMS-local-IP-address:3483 -L
localhost:34831:LMS-local-IP-address:34831 LMS-dns-address
On the laptop I run this to send udp for 3483 to tcp port 34831:
Code:
socat -T15 udp4-recvfrom:3483,reuseaddr,fork tcp:localhost:34831
On the server:
Code:
socat tcp4-listen:34831,reuseaddr,fork UDP:localhost:3483
Thanks very much for your help. I have still singularly failed to solve
the tolua++ make file issue on my laptop (on thread
http://forums.slimdevices.com/showthread.php?107349-Best-place-to-download-Squeezeplay),
which is very puzzling, but I do now have a working solution.
LMS 7.9.1 on VortexBox Midi box, Xubuntu 17.10, FLACs 16->24 bit,
44.1->192kbps. Touch & EDO. 2nd Touch standard.
LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (to A308CR amp & ESLs) &
Marantz CR603 UPnP renderers.
Alternatively Minimserver & Upplay to same & to upmpdcli/mpd PC
renderers.
Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones.
Wireless Xubuntu 17.10 laptop firefox/upplay or Android 'phone with
Squeeze-Commander/BubbleUPnP controls LMS/Minimserver.
PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642
View this thread: http://forums.slimdevices.com/showthread.php?t=108734
___
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
ralphy wrote: > The ssh -L feature only forwards TCP ports, so it works fine for > squeezelite as long as you specify your lms server using -s lmshost as > UDP is only used in the server discovery code. Squeezeplay expects UDP > ports to be available (ie. forwarded) as well. Squeezeplay does work > when using a vpn solution like openvpn. > > You may be able to get squeezeplay working with ssh by editing a couple > of setting files as discussed in 'the thread' > (http://forums.slimdevices.com/showthread.php?101388-Squeezeplay-won-t-connect-after-clean-install-of-Win-7-Pro/page2). > I've had mixed success with this method. Thanks. I don't see any specific recommendation for ...lua file settings in that thread, but the explanation of why it doesn't work is most helpful. On doing a little googling I believe there are ways of using UDP over ssh, so I'll have a crack at that, presumably with port 3483. LMS 7.9.1 on VortexBox Midi box, Xubuntu 17.10, FLACs 16->24 bit, 44.1->192kbps. Touch & EDO. 2nd Touch standard. LMS plugin UPnP/DLNA Bridge to MF M1 CLiC (to A308CR amp & ESLs) & Marantz CR603 UPnP renderers. Alternatively Minimserver & Upplay to same & to upmpdcli/mpd PC renderers. Squeezelite to Meridian USB Explorer DAC to PC speakers/headphones. Wireless Xubuntu 17.10 laptop firefox/upplay or Android 'phone with Squeeze-Commander/BubbleUPnP controls LMS/Minimserver. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Problems getting squeezeplay to work remotely over ssh
The ssh -L feature only forwards TCP ports, so it works fine for squeezelite as long as you specify your lms server using -s lmshost as UDP is only used in the server discovery code. Squeezeplay expects UDP ports to be available (ie. forwarded) as well. Squeezeplay does work when using a vpn solution like openvpn. You may be able to get squeezeplay working with ssh by editing a couple of setting files as discussed in 'the thread' (http://forums.slimdevices.com/showthread.php?101388-Squeezeplay-won-t-connect-after-clean-install-of-Win-7-Pro/page2). I've had mixed success with this method. Ralphy *1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio 'Squeezebox client builds' (https://sourceforge.net/projects/lmsclients/files/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations=LL5P6365KQEXN=CA_name=Squeezebox%20client%20builds_code=USD=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
