Bug 9700

Summary:	Pulseaudio & NFS port conflict 16001
Product:	Mageia	Reporter:	claire robinson <eeeemail>
Component:	RPM Packages	Assignee:	Colin Guthrie <mageia>
Status:	RESOLVED OLD	QA Contact:
Severity:	normal
Priority:	Normal	CC:	marja11
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	pulseaudio? nfs? portreserve?	CVE:
Status comment:

Description claire robinson 2013-04-11 12:41:08 CEST

Backstory:

I've been trying for a while to get network audio to work via pulseaudio to use a remote computer as an audio sink.

I could get the local computer to see the remote audio sink in kde phonon settings but it was always unavailable and greyed out. It wasn't available in pavucontrol.

Yesterday I was playing with nmap and checking open ports to clean up behind QA testing, found jetty, nfs, samba, mysql, ldap etc left behind from previous testing so did some spring cleaning and removed openldap-servers, samba-server, rpcbind and added skip-networking again to my.cnf.

I was trying to find what was still using port 16001 as googling suggested it was something to do with nfs but removing all I could think of left it still open.

netstat ap | grep 16001 showed pulseaudio listening on that port so I checked network audio again and it had started working.

I suspect a port conflict with nfs/rpcbind/portreserve and pulseaudio. I'm not familiar enough with nfs to debug it.

Feel free to say I'm imagining it :)

Reproducible: 

Steps to Reproduce:

Comment 1 Colin Guthrie 2013-04-11 15:08:28 CEST

Port 16001 is the port used by the ESound protocol which pulseaudio supports for backwards compatibility only.

Generally speaking, even if you are using remote sound, it will not be using ESound for this, but rather PulseAudio native protocol which is run on a different port entirely.

portreserve should really die now anyway as it's functions and capabilities are better implemented in systemd as .socket units. There will always be a fundamental issue of ports being already reserved for other things tho'. The best we can hope for is for tools to adapt dynamically and use different ports when possible and advertise this fact via avahi so the receiving end can adapt too. This doesn't work so well for "static" networking setups tho'.

Anyway, all in all, it's a hard one to "fix" specifically. Even if we did use systemd or portreserve it crosses over a boundary of root processes to user processes.

You're likely not imagining it tho', it may very well have been related in some way, but it's kinda hard to say for sure.

Comment 2 claire robinson 2013-04-11 15:58:51 CEST

I thought it worth reporting anyway Colin, I know people have had problems with NFS so wondered if it could be related.

Comment 3 Marja Van Waes 2016-06-24 21:19:53 CEST

This bug report saw no action in over 3 years.

Is it still valid?

Keywords: (none) => NEEDINFO
CC: (none) => marja11

Comment 4 claire robinson 2016-06-24 23:40:44 CEST

Times move on. Closing as old.

Status: NEW => RESOLVED
Resolution: (none) => OLD