How to redirect pulse audio through ssh?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110521/84f6ac19/attachment.htm>


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux