Hi,
I did a "LANG=C pulseaudio --system --high-priority -vvvv
>/root/pulseverbose.log 2>&1" on the client to write a detailed log file.
Here is the results when the remote client tries to connect:
-----------------------------------------------------------------
I: client.c: Created 9 "Native client (TCP/IP client from 127.0.0.1:50604)"
I: protocol-native.c: Client authenticated anonymously.
E: client-ext.c: client-ext.c: Can't obtain command line
D: client-ext.c: new/modified client (idx=9) (Native client (TCP/IP client
from 127.0.0.1:50604)|<noid>|0|0|<noexe>|<noarg>|<noargs>)
D: protocol-native.c: Protocol version: remote 16, local 16
D: protocol-native.c: SHM possible: no
D: protocol-native.c: Negotiated SHM: no
E: protocol-native.c: protocol error, kicking client
I: client.c: Freed 9 "Native client (TCP/IP client from 127.0.0.1:50604)"
D: client-ext.c: client removed (idx=9)
-----------------------------------------------------------------
Still have not got further to solving the "protocol error" problem. Maybe
something to do with SHM?
br,
Quinn
On Sat, May 21, 2011 at 5:14 PM, Quinn Plattel <qiet72 at gmail.com> wrote:
> Hi,
>
> Some more attempts. I have now tried this:
> client (session 1): stop pulseaudio
> client (session 1): pulseaudio --system --high-priority -C
>
> client (session 2): ssh -R 4000:localhost:4000 user at server
> client (session 3): socat TCP-LISTEN:4000,fork
> UNIX-CONNECT:/var/run/pulse/native
>
> server: export PULSE_SERVER=localhost:4000
> server: pactl stat
>
> client (session 1) response (pulseaudio): E: protocol-native.c: protocol
> error, kicking client
>
> "protocol error" - how can we go deeper to debug the problem?
>
> Pulseaudio version information:
> server: 0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14
> client: 0.9.15-1maemo43+0m5
>
> client pulseaudio modules loaded (pactl list|grep "Name: module")
> -----------------------------------------------
> Name: module-native-protocol-unix
> Name: module-simple-protocol-unix
> Name: module-stream-restore
> Name: module-rescue-streams
> Name: module-suspend-on-idle
> Name: module-augment-properties
> Name: module-null-sink
> Name: module-alsa-sink-old
> Name: module-alsa-sink-volume
> Name: module-alsa-source-old
> Name: module-nokia-voice
> Name: module-nokia-music
> Name: module-nokia-record
> Name: module-alsa-sink-old
> Name: module-alsa-source-old
> Name: module-bluetooth-discover
> Name: module-combine
> Name: module-esound-protocol-unix
> Name: module-native-protocol-tcp
> Name: module-policy-enforcement
> Name: module-match
> Name: module-cli
> -----------------------------------------------
>
> br,
> Quinn
>
>
> On Sat, May 21, 2011 at 11:29 AM, Quinn Plattel <qiet72 at gmail.com> wrote:
>
>> 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
>>
>
>
>
> --
> 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/bb9bef15/attachment.htm>
