Bug 9700 - Pulseaudio & NFS port conflict 16001
Summary: Pulseaudio & NFS port conflict 16001
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2013-04-11 12:41 CEST by claire robinson
Modified: 2016-06-24 23:40 CEST (History)
1 user (show)

See Also:
Source RPM: pulseaudio? nfs? portreserve?
CVE:
Status comment:


Attachments

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


Note You need to log in before you can comment on or make changes to this bug.