Hi all,
I have weird sound issues with pyhoca-cli and need a hint, where to look :)
Scenario: debian wheezy (uptodate) client with KDE running conncts to a debian wheezy (also uptodate) server with KDE.
Following versions:
root@client: ~ # dpkg -l | egrep 'x2go|pyhoca' ii pyhoca-cli 0.4.0.1-0~x2go1+wheezy~main~171~build1 all Command line X2Go client written in Python ii pyhoca-gui 0.4.0.8-0~x2go1+wheezy~main~1082~build1 all Graphical X2Go client written in (wx)Python ii python-x2go 0.4.0.8-0~x2go1+wheezy~main~1095~build1 all Python module providing X2Go client API ii x2goclient 4.0.1.1-0~x2go1+wheezy~main~427~build1 amd64 X2Go Client application (Qt4)
root@server: ~ # dpkg -l | egrep 'x2go|pyhoca' ii x2go-keyring 2012.07.23+wheezy~main~17~build1 all GnuPG keys of all X2Go developers and the X2Go archive ii x2goagent 2:3.5.0.21-0+wheezy~main~423~build1 all X2Go agent ii x2goserver 4.0.1.6-0~x2go1+wheezy~main~712~build1 i386 X2Go server daemon scripts ii x2goserver-compat 4.0.1.6-0~x2go1+wheezy~main~712~build1 all X2Go server daemon scripts (backwards compatitbity to old client versions) ii x2goserver-extensions 4.0.1.6-0~x2go1+wheezy~main~712~build1 all X2Go server daemon scripts (extensions) ii x2goserver-xsession 4.0.1.6-0~x2go1+wheezy~main~712~build1 all X2Go server daemon scripts (Xsession runner)
If I try to connect from client (within a fresh KDE session) to server with the following command, I don't have any sound in this x2gosession:
pyhoca-cli --server $SERVER --new --command startkde --username $USR --sound pulse --geometry 1440x900 --link adsl --pack 16m-png-9 --kbd-layout de --kbd-type '105/de'
Now I connect to the server (or another x2goserver, that doesn't matter) with x2goclient and there is sound. When I then connect again with above pyhoca-cli command, I have sound in this session.
When I restart the local KDE Desktop on the client, I don't have any sound with pyhoca, until I connect with x2goclient ...
I think, there is some process/program, that pyhoca-cli is not able to start, until x2goclient will start it, but I can't find it ...
Help appreciatet :)
So long, Tim
Am 14.10.2013 13:51, schrieb Tim Kruse:
[...]
If I try to connect from client (within a fresh KDE session) to server with the following command, I don't have any sound in this x2gosession:
pyhoca-cli --server $SERVER --new --command startkde --username $USR --sound pulse --geometry 1440x900 --link adsl --pack 16m-png-9 --kbd-layout de --kbd-type '105/de'
Now I connect to the server (or another x2goserver, that doesn't matter) with x2goclient and there is sound. When I then connect again with above pyhoca-cli command, I have sound in this session.
When I restart the local KDE Desktop on the client, I don't have any sound with pyhoca, until I connect with x2goclient ...
I think, there is some process/program, that pyhoca-cli is not able to start, until x2goclient will start it, but I can't find it ...
An update about this ...
I digged into this problem a bit deeper and found one inportant difference. The pulseaudio deamon get's started with KDE, so this is ok:
ps -ef | grep pulse tkruse 3887 1 0 07:02 ? 00:00:00 /usr/bin/pulseaudio --start --log-target=syslog
But at this time no TCP port for pulseaudio is opened, so that no network sound connection is possible (I use the standard port 4713). If I start pyhoca-cli, it does not open the port (or is not able to, dunno). X2Goclient DOES open the port, so that the connection can be made. If I close the x2goclient session, the port remains open, so now a pyhoca-cli session has sound, too.
I started pyhoca-cli with --debug --libdebug and got the messages
pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: notifying thread of incoming channel: <X2GoRevFwTunnel(Thread-5, started daemon 24821416)> pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: detected incoming data channel on X2Go server port: [127.0.0.1]:30089 pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: data channel <paramiko.Channel 14 (open) window=2097152 -> <paramiko.Transport at 0x1813710L (cipher aes128-ctr, 128 bits) (active; 2 open channel(s))>> for server port [127.0.0.1]:30089 is up pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: waiting for incoming data channel on X2Go server port: [127.0.0.1]:30089
which is clear, as there is no open port 4713.
So, if pyhoca or python-x2go is not able to handle this, is there a chance to let pulseaudio open this port otherwise? I think of some kind of script, which will be executed before pyhoca ...
So long, Tim
Am 16.10.2013 12:44, schrieb Tim Kruse:
I started pyhoca-cli with --debug --libdebug and got the messages
pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: notifying thread of incoming channel: <X2GoRevFwTunnel(Thread-5, started daemon 24821416)> pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: detected incoming data channel on X2Go server port: [127.0.0.1]:30089 pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: data channel <paramiko.Channel 14 (open) window=2097152 -> <paramiko.Transport at 0x1813710L (cipher aes128-ctr, 128 bits) (active; 2 open channel(s))>> for server port [127.0.0.1]:30089 is up pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: waiting for incoming data channel on X2Go server port: [127.0.0.1]:30089
Sorry, copy'n'paste hell:
pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: notifying thread of incoming channel: <X2GoRevFwTunnel(Thread-5, started daemon 24821416)> pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: detected incoming data channel on X2Go server port: [127.0.0.1]:30089 pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: data channel <paramiko.Channel 14 (open) window=2097152 -> <paramiko.Transport at 0x1813710L (cipher aes128-ctr, 128 bits) (active; 2 open channel(s))>> for server port [127.0.0.1]:30089 is up pyhoca-cli[10399] (x2gorevtunnel-pylib) DEBUG: waiting for incoming data channel on X2Go server port: [127.0.0.1]:30089 pyhoca-cli[10399] (x2gorevtunnel-pylib) INFO: Reverse forwarding request to 127.0.0.1:4713 failed: error(111, 'Connection refused')
The last INFO line ...
Am 16.10.2013 12:44, schrieb Tim Kruse:
which is clear, as there is no open port 4713.
So, if pyhoca or python-x2go is not able to handle this, is there a chance to let pulseaudio open this port otherwise? I think of some kind of script, which will be executed before pyhoca ...
I got it:
pacmd load-module module-native-protocol-tcp listen=0.0.0.0
before the start of pyhoca-cli let the running pulseaudio deamon open it's port. Or let pulseaudio open the port by default by adding the above line to /etc/pulse/default.pa ...
Perhaps it's possible to let pyhoca, or python-x2go respectively, open the port like x2goclient does ... but for me the above solution is enough ...
So long, Tim
Hi Tim,
On Mi 16 Okt 2013 13:23:19 CEST, Tim Kruse wrote:
Am 16.10.2013 12:44, schrieb Tim Kruse:
which is clear, as there is no open port 4713.
So, if pyhoca or python-x2go is not able to handle this, is there a chance to let pulseaudio open this port otherwise? I think of some kind of script, which will be executed before pyhoca ...
I got it:
pacmd load-module module-native-protocol-tcp listen=0.0.0.0
before the start of pyhoca-cli let the running pulseaudio deamon
open it's port. Or let pulseaudio open the port by default by adding
the above line to /etc/pulse/default.pa ...Perhaps it's possible to let pyhoca, or python-x2go respectively,
open the port like x2goclient does ... but for me the above solution
is enough ...So long, Tim
Very cool! Thanks for diving into this.
I have filed a wishlist bug for that, so that we get that pacmd call
into python-x2go in the near future.
Cheers, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Tim,
On Mi 16 Okt 2013 13:23:19 CEST, Tim Kruse wrote:
pacmd load-module module-native-protocol-tcp listen=0.0.0.0
For X2Go, it is sufficient to make pulseaudio listen on 127.0.0.1. The
internal (tunneled) communication in X2Go is forced to IPv4, so no
need to listen on [::1], the IPv4 localhost address should be just fine.
Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 21.10.2013 13:06, schrieb Mike Gabriel:
Hi Tim,
On Mi 16 Okt 2013 13:23:19 CEST, Tim Kruse wrote:
pacmd load-module module-native-protocol-tcp listen=0.0.0.0
For X2Go, it is sufficient to make pulseaudio listen on 127.0.0.1. The internal (tunneled) communication in X2Go is forced to IPv4, so no need to listen on [::1], the IPv4 localhost address should be just fine.
For IPv6 that's absolutely right. For IPv4 it depends on your setup. We don't tunnel audio through SSH, so localhost is not enough. I could use the LAN IP address of the client in the listen directive and be fine, I think ...
(So, why don't tunnel audio through SSH, you may ask. IPVS as our loadbalancing solution has one problem with this scenario. If i understood it correctly, with tunneled audio you have at least two SSH Streams, ipvsadm want's to forward to two different x2goservers. As we have no need to tunnel, we deactevated the tunneling option and i didn't dig to the problem deeper)
Greetz,
Tim
Hi Tim,
On Mo 21 Okt 2013 17:33:24 CEST, Tim Kruse wrote:
Am 21.10.2013 13:06, schrieb Mike Gabriel:
Hi Tim,
On Mi 16 Okt 2013 13:23:19 CEST, Tim Kruse wrote:
pacmd load-module module-native-protocol-tcp listen=0.0.0.0
For X2Go, it is sufficient to make pulseaudio listen on 127.0.0.1. The internal (tunneled) communication in X2Go is forced to IPv4, so no need to listen on [::1], the IPv4 localhost address should be just fine.
For IPv6 that's absolutely right. For IPv4 it depends on your setup.
We don't tunnel audio through SSH, so localhost is not enough. I
could use the LAN IP address of the client in the listen directive
and be fine, I think ...(So, why don't tunnel audio through SSH, you may ask. IPVS as our
loadbalancing solution has one problem with this scenario. If i
understood it correctly, with tunneled audio you have at least two
SSH Streams, ipvsadm want's to forward to two different x2goservers.
As we have no need to tunnel, we deactevated the tunneling option
and i didn't dig to the problem deeper)
If you use pyhoca-cli (python-x2go) then your audio stream is always
tunneled. Python X2Go ignores the soundtunnel={true,false} switch. It
always tunnels audio stream through the main SSH connection. Actually,
a load-balancer should not be able to notice the audio stream inside
the main SSH connection. The audio stream is pushed through a reverse
port forwarding SSH tunnel.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 21.10.2013 22:27, schrieb Mike Gabriel:
[...] (So, why don't tunnel audio through SSH, you may ask. IPVS as our loadbalancing solution has one problem with this scenario. If i understood it correctly, with tunneled audio you have at least two SSH Streams, ipvsadm want's to forward to two different x2goservers. As we have no need to tunnel, we deactevated the tunneling option and i didn't dig to the problem deeper)
If you use pyhoca-cli (python-x2go) then your audio stream is always tunneled. Python X2Go ignores the soundtunnel={true,false} switch. It always tunnels audio stream through the main SSH connection. Actually, a load-balancer should not be able to notice the audio stream inside the main SSH connection. The audio stream is pushed through a reverse port forwarding SSH tunnel.
Ok, that's good to know :)
I was trying the LVS loadbalancing with x2goclient and had those effects, I was describing above. When I disabled the tunneling, everything ran as wanted ...
I'll try 127.0.0.1 with pyhoca-cli and send the results to the list
Greetz
Am 22.10.2013 09:39, schrieb Tim Kruse:
I'll try 127.0.0.1 with pyhoca-cli and send the results to the list
So, I made that try and it's really enough, to get sound, which increases security.
pacmd load-module module-native-protocol-tcp listen=127.0.0.1
Good point, Mike, thx :)
Greetz
-
Mike Gabriel -
Tim Kruse