[Thinlinc-technical] sshd error msg

h zerbes heze54 at gmail.com
Tue Jan 18 12:29:48 CET 2011


First, my apologies to Rudi and Wesley for getting these emails! Looks like the
mailing list got mixed up somehow and I'm sure Peter will be able to sort it
out. For the record, I didn't sent the mails to you directly, gents, just cc'ed
thinlinc-technical at lists.cendio.se.

And if you gents have never heard of thinlinc, feel free to check it out! :-|

I only came about it a few days ago while researching different VDI solutions
for our IT security consultancy here at surecity.com.au and already think it's a
great product. (And I'm not even related to Peter...;-) )

Follow-up mails from me will go to Peter directly unless he objects.

On 18/01/11 21:14, Peter Åstrand wrote:
>
> I've done some testing on a Ubuntu 10.04 machine. I've also noticed that
> connections to the sound tunnel happens every 2 seconds or so. There are two
> processes responsible for this:

Thanks a lot for your testing and verification of the issue, Peter!

It's true that sound is not working while using the thinlinc client.

The ssh client seems to use a whole stack (read: 6) of redirects on the remote
server:

$ pgrep -l -f /opt/thinlinc/lib/tlclient/ssh
14757 /opt/thinlinc/lib/tlclient/ssh -N -o PubkeyAuthentication=no -o
CheckHostIP=no -o NumberOfPasswordPrompts=1 guest at 172.27.26.205 -p 22 -L
36488:127.0.0.1:5901 -R 4910:127.0.0.1:34438 -R 4915:127.0.0.1:35093 -R
4916:127.0.0.1:54180 -R 4914:127.0.0.1:39659 -R 4913:127.0.0.1:37192

whereas the server has these ports open:

root at srv205:~# netstat -atn | grep LIST
tcp        0      0 127.0.0.1:4910          0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:4913          0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:4914          0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:1010            0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:4915          0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:4916          0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:6011          0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN    
tcp        0      0 0.0.0.0:904             0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:5901          0.0.0.0:*               LISTEN    


the client, OTOH, is missing two of them (34438,35093):

$ netstat -atn | grep LIST | egrep "36488|34438|35093|54180|39659|37192"
tcp        0      0 127.0.0.1:54180         0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:37192         0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:36488         0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:39659         0.0.0.0:*               LISTEN    
tcp6       0      0 ::1:36488               :::*                    LISTEN    



>
> /usr/lib/gnome-settings-daemon/gnome-settings-daemon
> /usr/lib/indicator-sound/indicator-sound-service
>
> This is probably normal behaviour.

"Sound" and "normal" don't go well together recently on Ubuntu, I have to admin :-(

But yes, if I turn off sound on the thinlinc client, I don't get the error msgs
anymore.

> I've also managed to reproduce the "connect failed: Connection refused" error.
> It happens if you have requested Sound redirection in the client, but the
> client side sound server (PulseAudio) is not running. I can reproduce this
> problem by killing it manually.
>
> Probably, you get this error because PulseAudio on the client side fails or
> crashes. You should be able to see this in tlclient.log.

Hmm, seems like there is only the current and one old log being kept? Just as
well the .old.log one still contained the error as you predicted:

2011-01-18T22:08:55: VNC command: /opt/thinlinc/lib/tlclient/vncviewer
-FullColour=1 -LowColourLevel=2 -AutoSelect=1 -CustomCompressLevel=0
-CompressLevel=6 -QualityLevel=8 -PasswordFile=/tmp/vncvi
ewerYgkyVy -Shared=1 -DesktopSize=1280x900 127.0.0.1::36488
2011-01-18T22:08:55: PulseAudio command: /opt/thinlinc/lib/tlclient/pulseaudio
-n --use-pid-file=false -L "module-esound-protocol-tcp listen=127.0.0.1
port=34438 cookie='/tmp/esdLehWxT'" -L "module
-native-protocol-tcp listen=127.0.0.1 port=35093 cookie='/tmp/pulseaudionIOkae'"
--fail=false -L module-alsa-sink -L module-alsa-source -L module-oss
--log-level=notice
2011-01-18T22:08:55: PulseAudio pid is 14758
2011-01-18T22:08:55: Smart card daemon command:
/opt/thinlinc/lib/tlclient/pcsctun -b 127.0.0.1 -p 54180 -c /tmp/pcsctundngaOy
2011-01-18T22:08:55: smart card daemon pid is 14759
2011-01-18T22:08:55: unfsd command: /opt/thinlinc/lib/tlclient/unfsd -d -e
/tmp/unfsdtJL8sT -n 39659 -m 39659 -l 127.0.0.1 -t -p -s
2011-01-18T22:08:55: unfsd pid is 14760
2011-01-18T22:08:56: vncviewer pid is 14761
2011-01-18T22:08:56: unfsd: UNFS3 unfsd 0.9.20 (C) 2006, Pascal Schmidt
<unfs3-server at ewetel.net>
2011-01-18T22:08:56: unfsd: /media/cdrom: ip 127.0.0.1 mask 255.255.255.255
options 24
2011-01-18T22:08:56: unfsd: /media/floppy: ip 127.0.0.1 mask 255.255.255.255
options 28
2011-01-18T22:08:56: vncviewer:
2011-01-18T22:08:56: vncviewer: ThinLinc Client for X - built Oct 15 2010 01:27:54
2011-01-18T22:08:56: vncviewer: Based on TigerVNC viewer - see
http://www.tigervnc.org
2011-01-18T22:08:56: vncviewer: Copyright (C) 2002-2005 RealVNC Ltd.
2011-01-18T22:08:56: vncviewer: Copyright (C) 2000-2006 TightVNC Group
2011-01-18T22:08:56: vncviewer: Copyright (C) 2004-2009 Peter Astrand for Cendio AB
2011-01-18T22:08:56: vncviewer: See included EULA.txt for licensing details.
2011-01-18T22:08:56: vncviewer: See http://www.cendio.com for information on
ThinLinc.
2011-01-18T22:08:56: pulseaudio: pulseaudio: pulsecore/pdispatch.c:136:
pa_pdispatch_new: Assertion `(entries && table) || (!entries && !table)' failed.
2011-01-18T22:08:56: vncviewer:
2011-01-18T22:08:56: vncviewer: Tue Jan 18 22:08:56 2011
2011-01-18T22:08:56: vncviewer:  CConn:       connected to host 127.0.0.1 port 36488
2011-01-18T22:08:56: vncviewer:  CConnection: Server supports RFB protocol
version 3.8
2011-01-18T22:08:56: vncviewer:  CConnection: Using RFB protocol version 3.8
2011-01-18T22:08:56: vncviewer:  TXImage:     Using default colormap and visual,
TrueColor, depth 24.
2011-01-18T22:08:56: vncviewer:  CConn:       Using pixel format depth 24
(32bpp) little-endian rgb888
2011-01-18T22:08:56: vncviewer:  CConn:       Using Tight encoding
2011-01-18T22:08:56: Process 14758 killed by signal 6
2011-01-18T22:16:26: vncviewer:
2011-01-18T22:16:26: vncviewer: Tue Jan 18 22:16:26 2011
2011-01-18T22:16:26: vncviewer:  main:        End of stream
2011-01-18T22:16:26: Process 14761 exited with code 0
2011-01-18T22:16:27: Log file ended


>
> We have a known issue with the PulseAudio included with our client: It fails
> on system with the Alsa PulseAudio plugin. On Fedora, you can work around the
> problem by uninstalling the package alsa-plugins-pulseaudio. On Ubuntu 9.04,
> you must instead change the configuration. For example, you can rename
> /usr/share/alsa/pulse-alsa.conf. We haven't verified if this also works on 10.04.
>
> This problem will be fixed in the next release.
>
> If you don't need sound, you can also just clear the Sound checkbox in the
> client GUI. That should get rid of these messages.


It did, thanks a lot for that, Peter! Who doesn't want to have a happy UNIX
system under his shell?
Sound works in general on the client machine and pulse-audio is running on both,
client and server.

Well, as mentioned, I've only started looking thinlinc and sound would certainly
be a "nice to have" for me and a "must have" for potential  customers, if they
were to migrate completely to thinlinc. This was the first problem I noticed
while test driving it. I'd still have to read up a bit more in the manual and
check out some of the other thinlinc features.

All the best, Peter, thanks again for the quick help and keep up the good work!

I'd like to be able to introduce thinlinc here in Australia in the future.
heinz











More information about the Thinlinc-technical mailing list