Ubuntu

pulseaudio floods network with multicast packets

Reported by Oded Arbel on 2009-08-10
98
This bug affects 16 people
Affects Status Importance Assigned to Milestone
pulseaudio (Debian)
Incomplete
Unknown
pulseaudio (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: pulseaudio

Since a karmic update last week, when pulseaudio is running it floods the network with multicast packets, to the point where the wireless interface I'm using is so flooded that no other network traffic can be transfered.

Here is a snippet of tcpdump -i wlan 0 -n:
---8<---
01:10:36.532748 IP (tos 0x10, ttl 1, id 23823, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d0f 4000 0111 2d6d 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f9f6 800a ee8e
 0x0020: 0071 a980 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.539999 IP (tos 0x10, ttl 1, id 23824, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d10 4000 0111 2d6c 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f8b5 800a ee8f
 0x0020: 0071 aac0 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.547289 IP (tos 0x10, ttl 1, id 23825, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d11 4000 0111 2d6b 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f774 800a ee90
 0x0020: 0071 ac00 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.556725 IP (tos 0x10, ttl 1, id 23826, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d12 4000 0111 2d6a 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f633 800a ee91
 0x0020: 0071 ad40 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.561680 IP (tos 0x10, ttl 1, id 23827, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d13 4000 0111 2d69 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f4f2 800a ee92
 0x0020: 0071 ae80 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.568984 IP (tos 0x10, ttl 1, id 23828, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d14 4000 0111 2d68 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f3b1 800a ee93
 0x0020: 0071 afc0 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.576212 IP (tos 0x10, ttl 1, id 23829, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d15 4000 0111 2d67 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f270 800a ee94
 0x0020: 0071 b100 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.588095 IP (tos 0x10, ttl 1, id 23830, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d16 4000 0111 2d66 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 f12f 800a ee95
 0x0020: 0071 b240 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.590645 IP (tos 0x10, ttl 1, id 23831, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d17 4000 0111 2d65 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 efee 800a ee96
 0x0020: 0071 b380 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.605081 IP (tos 0x10, ttl 1, id 23832, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d18 4000 0111 2d64 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 eead 800a ee97
 0x0020: 0071 b4c0 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.612355 IP (tos 0x10, ttl 1, id 23833, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d19 4000 0111 2d63 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 ed6c 800a ee98
 0x0020: 0071 b600 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.619789 IP (tos 0x10, ttl 1, id 23834, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d1a 4000 0111 2d62 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 ec2b 800a ee99
 0x0020: 0071 b740 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.627001 IP (tos 0x10, ttl 1, id 23835, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d1b 4000 0111 2d61 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 eaea 800a ee9a
 0x0020: 0071 b880 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.634033 IP (tos 0x10, ttl 1, id 23836, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d1c 4000 0111 2d60 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e9a9 800a ee9b
 0x0020: 0071 b9c0 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.643178 IP (tos 0x10, ttl 1, id 23837, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d1d 4000 0111 2d5f 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e868 800a ee9c
 0x0020: 0071 bb00 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.648509 IP (tos 0x10, ttl 1, id 23838, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d1e 4000 0111 2d5e 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e727 800a ee9d
 0x0020: 0071 bc40 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.655723 IP (tos 0x10, ttl 1, id 23839, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d1f 4000 0111 2d5d 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e5e6 800a ee9e
 0x0020: 0071 bd80 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.662926 IP (tos 0x10, ttl 1, id 23840, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d20 4000 0111 2d5c 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e4a5 800a ee9f
 0x0020: 0071 bec0 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.670210 IP (tos 0x10, ttl 1, id 23841, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d21 4000 0111 2d5b 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e364 800a eea0
 0x0020: 0071 c000 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.679610 IP (tos 0x10, ttl 1, id 23842, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d22 4000 0111 2d5a 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e223 800a eea1
 0x0020: 0071 c140 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
01:10:36.684789 IP (tos 0x10, ttl 1, id 23843, offset 0, flags [DF], proto UDP (17), length 1320)
    10.0.0.1.45232 > 224.0.0.56.46812: UDP, length 1292
 0x0000: 4510 0528 5d23 4000 0111 2d59 0a00 0001
 0x0010: e000 0038 b0b0 b6dc 0514 e0e2 800a eea2
 0x0020: 0071 c280 ed51 a42b 0000 0000 0000 0000
 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
 0x0040: 0000 0000 0000 0000 0000 0000
---8<---

As can be seen, these packets are sent several hundreds times a second and this completely overloads the network interface.

Apparently I have pulseaudio set with network access enabled, but I can't disable it as the pulseaudio configuration is completely disabled (see screenshot).

As pulseaudio keeps recovering itself the only way I can get any work done at the moment is to run "while true; do killall pulseaudio; sleep 1; done" whenever I want to do anything on the network.

Oded Arbel (oded-geek) wrote :

The multicast/RTP configuration is also disabled (see screenshot) - The only configuration accessible is the simultaneous output.

Oded Arbel (oded-geek) wrote :

I get this in the syslog - though it might be relevant:
---8<---
Aug 11 01:26:28 sepiroth pulseaudio[13073]: module-rtp-recv.c: Detected RTP packet loop!
---8<---

Oded Arbel (oded-geek) wrote :

See attached file with pulseaudio log debug mode running for a couple of minutes. It starts flooding the network immediately as it goes up, it then later started with the alsa-sink rewind stuff, which I'm pretty sure is not related.

Oded Arbel (oded-geek) wrote :

If I use padevchooser to specifically choose the internal audio as both default sink and default source, the network traffic is reduces somewhat but not by a lot (about 10%~20%).

I can cause pulseaudio to stop flooding the network completely by disabling the rtp-send module using gconf. I'll keep it disabled for now (as I do not have a real need at the moment for audio over the network) unless you want me to debug something.

darthanubis (darthanubis) wrote :

Same issue observed here.

Changed in pulseaudio (Ubuntu):
status: New → Confirmed
Changed in pulseaudio (Ubuntu):
importance: Undecided → Low
Tim Wright (timw) wrote :

Could you possibly explain why is this "Low" importance?
The bug means that anyone running Pulseaudio (which is everyone, correct?) is essentially committing a denial-of-service attack on all machines on their network (unless this only applies to certain configurations). Surely this is at the very least a "Major" bug?

I just upgraded to Karmic on my test system and hit the exact same problem.

On Mon, Sep 28, 2009 at 7:07 PM, Tim Wright <email address hidden> wrote:
> Could you possibly explain why is this "Low" importance?

There's a known workaround; it's not reproducible in a default install
of Karmic; it's not reproducible in a dist-upgrade to Karmic from a
default install of Jaunty.

> The bug means that anyone running Pulseaudio (which is everyone, correct?) is essentially committing a denial-of-service attack on all machines on their network (unless this only applies to certain configurations). Surely this is at the very least a "Major" bug?

See above - only applies to certain configurations. Upstream work is
addressing this symptom.

No, it's not anymore a major bug than running a certain bash script
without proper ulimits set would be.

Tim Wright (timw) wrote :

Fascinating. I did an "apt-get install padevchooser" which was not installed after the system updated to Karmic and that seemed to turn rtp-send off and the system started behaving. That install pulled in paprefs and zeroconf support.

On reboot it started spewing again, and going into paprefs, rtp-send was enabled. However, paprefs allowed me to disable it and on rebooting after doing so, it is still disabled. Any attempt to enable it causes the looping behaviour. It seems to be taking its own broadcasts and responding to them.

Tim Wright (timw) wrote :

Thank you Daniel. That clarifies it. Is there any debug information I can collect that would be helpful. On my test system (AMD Athlon-64, forcedeth NIC driver), trying to enable rtp-send immediately causes the problem, so I have a good place to repro :-)

Andrew Higginson (azhigginson) wrote :

+1 here using latest natty. Surprised this hasn't been dealt with yet :(

Changed in pulseaudio (Debian):
status: Unknown → Incomplete
RonsonK (ronsonk) wrote :

I've installed the Natty Beta and am experiencing the same thing. Multicast/RTP is unchecked in Pulseaudio prefs, however, it's still spewing.

I have an Airport Express on my network as an audio gateway. All the packets are targeted at it. 185 KIB/s.

RonsonK (ronsonk) wrote :

My issue survived the upgrade to Natty Beta 2.

- Acer AspireOne netbook
- only occurs (for me) on a network with an Apple device attached configured to receive streaming audio i.e. I don't see the behaviour when connected to other networks
- only occurs using WLAN0, not ETH0
- problem did not occur under prior versions (10.10 back to 9.10)

Adam Bolte (boltronics) wrote :

I think I just saw this issue also. I was seeing a lot of traffic over my wireless NIC going directly to one of three Apple AirTunes devices on my work network (the one I had connected to previously). Even though I set "Internal Audio Analog Stereo" under Sound Preferences/Output tab - so the AirPort was not selected, PulseAudio still was going nuts with traffic to it.

Before I had a chance to look into it further, another sysadmin had password-protected the device (apparently others were complaining that they could no longer connect to it to play music and rebooting the AirPort multiple times wasn't helping) and I could immediately see the outgoing traffic on the laptop stopped.

I was so excited that I could finally play audio to these horrible proprietary devices (purchasing them wasn't my decision), but now it's password-protected I'm not sure PulseAudio can play to the device any more - even though I know what the device password is.

I should point out that the laptop in question was actually running Debian testing, so this likely needs to be dealt with upstream by the PA guys.

Qbert (qbert) wrote :

Experiencing this problem with Ubuntu 10.10 and pulseaudio "0.9.21-63-gd3efa-dirty" (no AirTunes connected, enabled or in any way connected to the network).

- Network gets flooded with multicast packets.
- Sends audio with huge latency and glitches to my Ubuntu Server 11.04

paprefs configured as:
- Disabled Multicast/RTP reciever
- Enabled Multicast/RTP sender with seperate audio device for PulseAudio Multicast/RTP.
- No other network settings enabled.

dwpbike (dwpbike) wrote :

it's alive and well. i'm here on my second day of searching. network sends jump to 90+kb/s whenever i play audio, regardless of location, source, and player. have no idea how i tripped this "feature", but will attempt above "fix".

10.04 running on hp touchsmart, which is neither touch nor smart.

dwpbike (dwpbike) wrote :

removed check mark from "enabled". hint: gconf-editor in terminal, system -> pulseaudio -> modules -> rtp-send

Boris Baelen (sjimmie) wrote :

Hi,

I would like to say that this problem is still there and is the reason why I am not able to stream audio using RTP.

I have all other options disbaled, discover network audio, etc...

When I turn on RTP sender this happens:
21:52:26.935440 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
21:52:26.942691 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
21:52:26.949926 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
21:52:26.957141 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
21:52:26.964376 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
21:52:26.971580 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
21:52:26.978862 IP 192.168.0.235.48718 > 224.0.0.56.46234: UDP, length 1292
...... NON STOP.

IT will flood my entire network!

Is there a fix already? I am running Ubuntu 12.10 64bit.

elhoir (jfarroyo82) wrote :

hi there,

i have hit this bug usint Ubuntu 13.04, PulseAudio 3.0

Dakota Schneider (dakota-5) wrote :

Confirming what appears to be this bug on 12.10. Noticed constant network usage of 150-200 Kb/sec outgoing, which was causing substantial slowing over wifi interface. Checked aroung and there were multiple connections spawned by pulseaudio.

Disabling network devices using paprefs completely eliminated pulseaudio generated connections and stopped the passive network utilization.

Dakota Schneider (dakota-5) wrote :

EDIT: Appears to be limited to Apple Airfoil/AirTunes compatibility plugin thingie. Disabled just "make discoverable Apple AirTunes devices available locally" and that cut the bandwidth. Normal PulseAudio network devices did not seem to experience the same bug.

Dakota Schneider (dakota-5) wrote :

EDIT: Checked Multicast/RTP: it appears the aforementioned plugin for Apple AirTunes forces the Multicast/RTP settings. Enabling Multicast/RTP independently of Apple AirTunes support yields same results. My apologies for the numerous comments.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.