Hi, I finally got some more details from pulseaudio. I did this on the client: ---------------------------------- # stop pulseaudio # pulseaudio --system --high-priority -C ---------------------------------- Now, when I run "pactl stat" on the server, pulseaudio on the client reports: -------------------------------------- E: client-ext.c: client-ext.c: Can't obtain command line E: protocol-native.c: protocol error, kicking client --------------------------------------- This is strange because pactl on the server side reports that the protocol version is the same on both the remote and the local side: ------------------------------------------ Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to localhost:4713... SHM possible: yes Protocol version: remote 16, local 16 Negotiated SHM: no Connection failure: Connection terminated ------------------------------------------ Any ideas? br, Quinn On Sat, May 21, 2011 at 10:53 AM, Quinn Plattel <qiet72 at gmail.com> wrote: > Hi, > > I found this message when I am trying to tunnel 4713 via ssh "ssh -L > 4713:localhost:4713 user at server": > ------------------------------------------------------------ > bind: Address already in use > channel_setup_fwd_listener: cannot listen to port: 4713 > Could not request local forwarding. > ------------------------------------------------------------ > > BUT, this seems to work "ssh -R 4713:localhost:4713 user at server" (notice > the "-R" parameter) > > So, it seems the forwarding direction has some say in this. Forwarding > from local to remote is not the right way, but forwarding from remote to > local is the correct way. > > "pactl stat" also seems to get a bit futher this time with the correct > tunnelling direction: > ------------------------------------------------------------------------- > > Using shared memory pool with 1024 slots of size 64.0 KiB each, total size > is 64.0 MiB, maximum usable slot size is 65472 > Trying to connect to localhost:4713... > SHM possible: yes > Protocol version: remote 16, local 16 > Negotiated SHM: no > Connection failure: Connection terminated > ------------------------------------------------------------------------- > > So now we are down from "connection refused" to "connection failure: > connection terminated". > > If I attach an strace to the pulseaudio process then this happens when > "pactl stat" tries to connect to it remotely: > --------------------------------------------------------------------------- > Process 1075 attached - interrupt to quit > restart_syscall(<... resuming interrupted call ...>) = 1 > accept(57, 0, NULL) = 66 > fcntl64(66, F_GETFD) = 0 > fcntl64(66, F_SETFD, FD_CLOEXEC) = 0 > setsockopt(57, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0 > setsockopt(57, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > setsockopt(57, SOL_IP, IP_TOS, [16], 4) = 0 > fcntl64(66, F_GETFL) = 0x2 (flags O_RDWR) > fcntl64(66, F_SETFL, O_RDWR|O_NONBLOCK) = 0 > fstat64(66, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 > getpeername(66, {sa_family=AF_INET, sin_port=htons(54205), > sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 > getpeername(66, {sa_family=AF_INET, sin_port=htons(54205), > sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 > setsockopt(66, SOL_SOCKET, SO_RCVBUF, [16344], 4) = 0 > setsockopt(66, SOL_SOCKET, SO_SNDBUF, [16344], 4) = 0 > getsockname(66, {sa_family=AF_INET, sin_port=htons(4713), > sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 > open("/proc/0/cmdline", O_RDONLY) = -1 ENOENT (No such file or > directory) > ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbed12ef4) = -1 ENOTTY > (Inappropriate ioctl for device) > write(2, "E: client-ext.c: client-ext.c: Ca"..., 57) = 57 > --------------------------------------------------------------------------- > > I am assuming the problem lies on the client side and not on the server > side. Any more ideas? How can I see what is going on with the pulseaudio > daemon when a remote client is trying to connect? > > br, > Quinn > > > On Sat, May 21, 2011 at 10:31 AM, Quinn Plattel <qiet72 at gmail.com> wrote: > >> Hi, >> >> From what Colin says, the standard port is 4713 for pulseaudio. As I said >> before all network ports are blocked except port 22 which is only for ssh >> connections. >> I should be able to tunnel port 4713 through ssh by doing this: "ssh -L >> 4713:localhost:4713 user at server". Then I can tell pulseaudio to use the >> servers local port 4713 which is automatically forwarded to the client's >> local port 4713. But from what "pactl stat" command is telling me, then >> port 4713 on the client side seems to be blocked as it is giving a >> "connection refused". I know the tunnelling works with ssh because I use >> vnc connections through ssh by "ssh -L 5901:localhost:5901 user at server" >> and that works perfectly with my vnc client and server solution. >> >> I am not sure if I can use "pactl load-module module-protocol-native-tcp" >> together with tunnelled tcp connections. I need more details on how to >> that. >> >> btw, I can see there is something listening on port 4713 on the client >> when I use the "netstat -an|grep 4713" command: >> --------------------------------------------------------- >> tcp 0 0 0.0.0.0:4713 0.0.0.0:* >> LISTEN >> --------------------------------------------------------- >> So now the question is why does the listener process on the client not >> accept pulseaudio data via the ssh tunnel? >> >> br, >> Quinn >> >> >> >> >> On Fri, May 20, 2011 at 7:15 PM, Fred Frigerio <ffrigerio at frigerio.us>wrote: >> >>> Have you tried redirecting the port in SSH? Then you get the native PA >>> with SSH. I am not sure if there is some standard port. >>> >>> Fred Frigerio >>> >>> >>> >>> >>> On Fri, May 20, 2011 at 1:01 PM, Quinn Plattel <qiet72 at gmail.com> wrote: >>> >>>> Here is pactl stat on the client side: >>>> >>>> >>>> PULSE_LOG=99 pactl stat >>>> ------------------------------------------------- >>>> Using private memory pool with 1024 slots of size 16,0 KiB each, total >>>> size is 16,0 MiB, maximum usable slot size is 16344 >>>> Trying to connect to >>>> /home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native... >>>> connect(): No such file or directory (2) >>>> Trying to connect to /var/run/pulse/native... >>>> SHM possible: no >>>> >>>> Protocol version: remote 16, local 16 >>>> Negotiated SHM: no >>>> Currently in use: 1 blocks containing 16,0 KiB bytes total. >>>> Allocated during whole lifetime: 263989 blocks containing 231,3 MiB >>>> bytes total. >>>> >>>> Sample cache size: 0 B >>>> User name: pulse >>>> Host Name: Nokia-N900 >>>> Server Name: pulseaudio >>>> Server Version: 0.9.15 >>>> Default Sample Specification: s16le 2ch 48000Hz >>>> >>>> Default Channel Map: front-left,front-right >>>> Default Sink: sink.music >>>> Default Source: source.record >>>> Cookie: 26e54bb2 >>>> ------------------------------------------------- >>>> >>>> br, >>>> Quinn >>>> >>>> >>>> On Fri, May 20, 2011 at 6:58 PM, Quinn Plattel <qiet72 at gmail.com>wrote: >>>> >>>>> Hi, >>>>> >>>>> This is interesting: >>>>> >>>>> client: ssh -XL 4713:localhost:4713 user at server >>>>> server: PULSE_LOG=99 pactl stat >>>>> ---------------------------------------- >>>>> Using shared memory pool with 1024 slots of size 64.0 KiB each, total >>>>> size is 64.0 MiB, maximum usable slot size is 65472 >>>>> Trying to connect to >>>>> /home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native... >>>>> SHM possible: yes >>>>> Protocol version: remote 16, local 16 >>>>> Negotiated SHM: yes >>>>> Currently in use: 1 blocks containing 63.9 KiB bytes total. >>>>> Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes >>>>> total. >>>>> Sample cache size: 0 B >>>>> User name: quinn >>>>> Host Name: server >>>>> Server Name: pulseaudio >>>>> Server Version: 0.9.21-63-gd3efa-dirty >>>>> Default Sample Specification: s16le 2ch 44100Hz >>>>> Default Channel Map: front-left,front-right >>>>> Default Sink: auto_null >>>>> Default Source: auto_null.monitor >>>>> Cookie: 6ccbf517 >>>>> ---------------------------------------- >>>>> server: export PULSE_SERVER=localhost:4713 >>>>> server: PULSE_LOG=99 pactl stat >>>>> --------------------------------------- >>>>> Using shared memory pool with 1024 slots of size 64.0 KiB each, total >>>>> size is 64.0 MiB, maximum usable slot size is 65472 >>>>> Trying to connect to localhost:4713... >>>>> connect(): Connection refused >>>>> Connection failure: Connection refused >>>>> --------------------------------------- >>>>> >>>>> Ideas? >>>>> >>>>> Quinn >>>>> >>>>> On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie <gmane at colin.guthr.ie>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and >>>>>> gimble: >>>>>> > I am currently trying to attempt to redirect pulse audio sound from >>>>>> a >>>>>> > server to a client through ssh. I am bit unclear on what the >>>>>> correct >>>>>> > way is of doing it. >>>>>> >>>>>> Firstly, I wrote up how our X11 piggy backing stuff work here: >>>>>> >>>>>> >>>>>> http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ >>>>>> >>>>>> >>>>>> Technically we do not tunnel over SSH directly (this can of course be >>>>>> done, but not automatically as SSH does not know about PA in the same >>>>>> way it knows about X11). We can however piggy back on the X11 >>>>>> forwarding >>>>>> built into SSH for our authentication (cookie) and server connection >>>>>> strings. >>>>>> >>>>>> If this is on a private network (direct routing) then the built in way >>>>>> is the best, but it doesn't go over SSH. You just need to ensure the >>>>>> machine you're sshing from has the netwrok protocol module loaded into >>>>>> PA (pactl load-module module-protocol-native-tcp, or put it in your >>>>>> default.pa) and make sure port 4713/tcp is open for external >>>>>> connections. >>>>>> >>>>>> Also ensure that module-x11-publish is loaded on the client side and >>>>>> you >>>>>> should get some interesting results from "xprop -root | grep PULSE". >>>>>> >>>>>> Then when you ssh with x11 forwarding running the xprop command on the >>>>>> remote machine should show you the same results. >>>>>> >>>>>> >>>>>> >>>>>> If you cannot use the direct connection, just setup TCP tunnels in >>>>>> your >>>>>> SSH config and then hack the PULSE_SERVER property or env var on the >>>>>> remote machine to point to e.g. localhost:4713 which will actually be >>>>>> a >>>>>> tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE >>>>>> stuff already forwarded should be enough for auth. >>>>>> >>>>>> For debugging connections: >>>>>> >>>>>> PULSE_LOG=99 pactl stat >>>>>> >>>>>> This shows you e.g. the server name it's trying to connect to etc. >>>>>> >>>>>> >>>>>> Hope that helps (although I wrote it really quick so apologies if it >>>>>> doesn't! I'll clarify later if needs be :D) >>>>>> >>>>>> Col >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Colin Guthrie >>>>>> gmane(at)colin.guthr.ie >>>>>> http://colin.guthr.ie/ >>>>>> >>>>>> Day Job: >>>>>> Tribalogic Limited [http://www.tribalogic.net/] >>>>>> Open Source: >>>>>> Mageia Contributor [http://www.mageia.org/] >>>>>> PulseAudio Hacker [http://www.pulseaudio.org/] >>>>>> Trac Hacker [http://trac.edgewall.org/] >>>>>> >>>>>> _______________________________________________ >>>>>> pulseaudio-discuss mailing list >>>>>> pulseaudio-discuss at mail.0pointer.de >>>>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards/Med venlig hilsen, >>>> Quinn Plattel >>>> >>>> _______________________________________________ >>>> pulseaudio-discuss mailing list >>>> pulseaudio-discuss at mail.0pointer.de >>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >>>> >>>> >>> >>> _______________________________________________ >>> pulseaudio-discuss mailing list >>> pulseaudio-discuss at mail.0pointer.de >>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >>> >>> >> >> >> -- >> Best regards/Med venlig hilsen, >> Quinn Plattel >> > > > > -- > Best regards/Med venlig hilsen, > Quinn Plattel > -- Best regards/Med venlig hilsen, Quinn Plattel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110521/5fe1e95e/attachment.htm>