Bug #411688 “pulseaudio floods network with multicast packets” : Bugs : pulseaudio package : Ubuntu

Revision history for this message

Oded Arbel (oded-geek) wrote on 2009-08-10:

#1

Pulseaudio network preferences are active but cannot be disabled Edit (37.3 KiB, image/png)

Revision history for this message

Oded Arbel (oded-geek) wrote on 2009-08-10:

#2

Screenshot-PulseAudio Preferences-2.png Edit (32.5 KiB, image/png)

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

Revision history for this message

Oded Arbel (oded-geek) wrote on 2009-08-10:

#3

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<---

Revision history for this message

Oded Arbel (oded-geek) wrote on 2009-08-10:

#4

pa-debug.log Edit (379.3 KiB, text/plain)

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.

Revision history for this message

Oded Arbel (oded-geek) wrote on 2009-08-10:

#5

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.

Revision history for this message

darthanubis (darthanubis) wrote on 2009-08-24:

#6

Same issue observed here.

Changed in pulseaudio (Ubuntu):
status:	New → Confirmed

Pedro Villavicencio (pedro) on 2009-09-01

Changed in pulseaudio (Ubuntu):
importance:	Undecided → Low

Revision history for this message

Tim Wright (timw) wrote on 2009-09-28:

#7

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.

Revision history for this message

Daniel T Chen (crimsun) wrote on 2009-09-28: Re: [Bug 411688] Re: pulseaudio floods network with multicast packets

#8

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.

Revision history for this message

Tim Wright (timw) wrote on 2009-09-28:

#9

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.

Revision history for this message

Tim Wright (timw) wrote on 2009-09-29:

#10

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 :-)

Revision history for this message

Andrew Higginson (azhigginson) wrote on 2011-03-20:

#11

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

Bug Watch Updater (bug-watch-updater) on 2011-03-23

Changed in pulseaudio (Debian):
status:	Unknown → Incomplete

Revision history for this message

RonsonK (ronsonk) wrote on 2011-04-13:

#12

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.

Revision history for this message

RonsonK (ronsonk) wrote on 2011-04-20:

#13

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)

Revision history for this message

Adam Bolte (boltronics) wrote on 2011-07-11:

#14

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.

Revision history for this message

Qbert (qbert) wrote on 2011-09-21:

#15

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.

Revision history for this message

In freedesktop.org Bugzilla #44777, TB2 (gt6) wrote on 2012-01-14:

#24

Download full text (5.4 KiB)

When I enable module-rtp-send either by ticking [x] Enable Multicast/RTP sender in paprefs or adding something like

load-module module-null-sink sink_name=rtp
load-module module-rtp-send

to /etc/pulse/default.pa, pulseaudio starts flooding the packet with more than 100 UDP packets per second. My router can't handle that and fails to serve any other devices. The network is practially DOS'd by pulseaudio.

Output from tcpdump -i eth0, as soon as the [x] Enable Multicast/RTP sender checkbox in paprefs is ticket, starts about 2 seconds later:

13:15:37.872284 IP 192.168.1.7.42051 > 224.0.0.56.sapv1: UDP, length 236
13:15:40.106404 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.113622 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.120879 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.128150 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.135305 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.142550 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.149782 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.157019 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.164254 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.171478 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.178687 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.185959 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.193206 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.200402 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.207614 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.214899 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.222118 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.229332 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.236563 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.243806 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.251050 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.258285 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.265471 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.272692 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.279998 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.287151 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.294461 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.301695 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.308892 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.316144 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.323376 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.330585 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.337884 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.345098 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.352285 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, ...

When I enable module-rtp-send either by ticking [x] Enable Multicast/RTP sender in paprefs or adding something like

load-module module-null-sink sink_name=rtp
load-module module-rtp-send

to /etc/pulse/default.pa, pulseaudio starts flooding the packet with more than 100 UDP packets per second. My router can't handle that and fails to serve any other devices. The network is practially DOS'd by pulseaudio.

Output from tcpdump -i eth0, as soon as the [x] Enable Multicast/RTP sender checkbox in paprefs is ticket, starts about 2 seconds later:

13:15:37.872284 IP 192.168.1.7.42051 > 224.0.0.56.sapv1: UDP, length 236
13:15:40.106404 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.113622 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.120879 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.128150 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.135305 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.142550 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.149782 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.157019 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.164254 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.171478 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.178687 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.185959 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.193206 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.200402 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.207614 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.214899 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.222118 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.229332 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.236563 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.243806 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.251050 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.258285 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.265471 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.272692 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.279998 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.287151 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.294461 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.301695 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.308892 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.316144 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.323376 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.330585 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.337884 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.345098 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.352285 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.359539 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.366760 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.374038 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.381829 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.388471 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.395700 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
13:15:40.402964 IP 192.168.1.7.53698 > 224.0.0.56.46808: UDP, length 1292
(...)

Some info:

pulseaudio -vvvvv says nothing interesting at all when enabling RTP.

[root@tachychineta shapeshifter]# uname -a
Linux tachychineta 3.1.5-1-ARCH #1 SMP PREEMPT Sun Dec 11 06:26:14 UTC 2011 i686 Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux

[root@tachychineta shapeshifter]# pacman -Qi $(pacman -Qq | grep pulse) | grep -e "Name" -e "Version"
Name           : libcanberra-pulse
Version        : 0.28-2
Name           : libpulse
Version        : 1.1-2
Name           : pulseaudio
Version        : 1.1-2
Name           : pulseaudio-alsa
Version        : 1-2
Name           : pulseaudio-equalizer-bzr
Version        : 4-4

[root@tachychineta shapeshifter]# grep -v "^#" /etc/pulse/default.pa | grep -v "^$"
.nofail
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
.fail
.endif
.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix
.ifexists module-gconf.so
.nofail
load-module module-gconf
.fail
.endif
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-intended-roles
load-module module-suspend-on-idle
.ifexists module-console-kit.so
.nofail
load-module module-console-kit
.fail
.endif
load-module module-position-event-sounds
load-module module-cork-music-on-phone
load-module module-filter-heuristics
load-module module-filter-apply
.ifexists module-dbus-protocol.so
load-module module-dbus-protocol
.endif

Revision history for this message

In freedesktop.org Bugzilla #44777, Arun Raghavan (arunraghavan) wrote on 2012-01-14:

#25

OP also linked to this: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688

Revision history for this message

In freedesktop.org Bugzilla #44777, Lops (lops777) wrote on 2012-06-13:

#26

Same issue. Using rtp-send causes flooding of my whole local network. Computer using pulseaudio is connected via LAN on a router. I am using Ubuntu 12.04 / 64bit. Other computers are connected via WLAN and they loose connection. Sometimes router crashes. Flooding has a bandwidth of 180 KByte/s.

I have seen in google that this problem is existing since at least 2008 !!!!! Why the guys report bugs but noone is caring??

Revision history for this message

In freedesktop.org Bugzilla #44777, Mathieumart1 (mathieumart1) wrote on 2012-09-23:

#27

Same thing here, rtp module is an insteresting feature but is just unusable. An update anyone on this problem ?

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2012-09-24:

#28

No updates. I'm not aware of anyone working on this.

Revision history for this message

dwpbike (dwpbike) wrote on 2012-12-07:

#16

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.

Revision history for this message

dwpbike (dwpbike) wrote on 2012-12-07:

#17

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

Revision history for this message

In freedesktop.org Bugzilla #44777, Alloftheinternetinone (alloftheinternetinone) wrote on 2013-02-17:

#29

Subscribing in hope of fix.

Revision history for this message

Boris Baelen (sjimmie) wrote on 2013-03-21:

#18

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.

Revision history for this message

In freedesktop.org Bugzilla #44777, Boris Baelen (sjimmie) wrote on 2013-03-21:

#30

Exactly the same problem here.
Running Ubuntu 12.10 64bit with pulseaudio 2.1

Revision history for this message

In freedesktop.org Bugzilla #44777, Thomas (kugel.) wrote on 2013-04-15:

#31

I have this problem too. My network becomes completely unusable.

I also observe a constant bandwidth of a bit less than 200KB/s. This fits the expected PCM data rate (176KB/s). But this shouldn't congest the network. And indeed the same bandwidth caused by module-tunnel-sink works completely fine.

Are our routers at fault or is something fishy with module-rtp-send?

Revision history for this message

elhoir (jfarroyo82) wrote on 2013-05-30:

#19

hi there,

i have hit this bug usint Ubuntu 13.04, PulseAudio 3.0

Revision history for this message

Dakota Schneider (dakota-5) wrote on 2013-06-30:

#20

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.

Revision history for this message

Dakota Schneider (dakota-5) wrote on 2013-06-30:

#21

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.

Revision history for this message

Dakota Schneider (dakota-5) wrote on 2013-06-30:

#22

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.

Revision history for this message

In freedesktop.org Bugzilla #44777, Jeff Fortin Tam (kiddo) wrote on 2013-07-03:

#32

Just confirming that I'm seeing that kind of behavior on Fedora 19 too (so not ubuntu-specific), enabling the Multicast/RTP sender will cause constant UDP upload activity towards 224.0.0.56, in my case at ~180 KB/s. I think this explains my other computer (laptop) having trouble associating to the wifi, even though this desktop computer is connected through a wired connection.

My router is basically new hardware (Netgear WNR3500L/U/v2) running the Tomato firmware, and I really doubt that anything is at fault on that side.

Revision history for this message

In freedesktop.org Bugzilla #44777, Bill-freedesktop-org-bugzilla (bill-freedesktop-org-bugzilla) wrote on 2014-01-19:

#33

Created attachment 92370
pcap - load-module module-rtp-send source=rtp.monitor

Adding a pcap of the traffic I get when loading module-rtp-send:

load-module module-rtp-send source=rtp.monitor

and doing nothing more than 'pulseaudio -k'. Jump down past packet 343 where the first SDP capture is, for meaningful wireshark display. It looks like there are two issues here:

1) I presume module-rtp-send shouldn't be sending a constant stream of zero-filled packets just by being loaded with no sources assigned to the sink. That seems really inefficient, especially if sound output is infrequent and/or you have a network with many computers and want to be able to support n-to-n source/sink setups (n number of constant all-zero multicast streams...).

2) I also saw the local WiFi network become crippled by the packet storm. I see in the capture a packet rate of 137 per second. I'm running a -n access point running OpenWRT 12.09 and have a solid 180Mbps+ connection, so I looked into a bit further and found:

a) multicast on wireless is effectively useless, or perhaps dangerous. Multicast packets always use the lowest possible data rate on WiFi, which causes them to consume all available bandwidth and crowd out all other traffic:

https://dev.openwrt.org/ticket/10271

It appears that even running multicast on a wired network where wifi access points are connected can cause a takedown of the wifi networks if the wifi access points aren't filtering multicast.

b) there are some proposals for fixing this in a later revision of 802.11 but nothing we can use for a long time.

c) there are a bunch of people who have tried to use PA with RTP and some Raspberry Pis to distribute music and they've crashed and burned. The Wiki should probably note that this shouldn't be attempted if there's a WiFi network involved. Still, there is strong demand for this use case, if not RTP necessarily.*

d) Multicast on WiFi is so bad that it's more efficient to wrap the UDP in TCP and proxy it at the gateway:

http://wiki.openwrt.org/doc/howto/udp_multicast
http://www.udpxy.com/index-en.html

In my testing, igmp snooping on OpenWRT (and presumably all of its derivatives) doesn't work yet. I wonder if supporting udpxy's protocol in PA would make sense for the WiFi use case. Perhaps smarter would be:

* there appears to be an evolving open source standard around the SlimProto

  http://wiki.slimdevices.com/index.php/SlimProtoTCPProtocol
  http://wiki.slimdevices.com/index.php/SlimProtoDeveloperGuide
  https://code.google.com/p/squeezelite/source/browse/slimproto.c
  http://wiki.slimdevices.com/index.php/Design_of_new-streaming
  http://wiki.slimdevices.com/index.php/Synchronization

and the LMS implementation is said to have excellent synchronization which looks to be handled fairly simply in the perl code. A PA sender and receiver that implemented a subset of squeeze might be neat to have - might even be usable with some of the hardware players. Note: LMS (perl) is GPLv2 but slimsqueeze (c) is GPLv3 so direct code-reuse into PA is probably not possible.

Created attachment 92370
pcap - load-module module-rtp-send source=rtp.monitor

Adding a pcap of the traffic I get when loading module-rtp-send:

load-module module-rtp-send source=rtp.monitor

and doing nothing more than 'pulseaudio -k'.  Jump down past packet 343 where the first SDP capture is, for meaningful wireshark display.  It looks like there are two issues here:

1) I presume module-rtp-send shouldn't be sending a constant stream of zero-filled packets just by being loaded with no sources assigned to the sink.  That seems really inefficient, especially if sound output is infrequent and/or you have a network with many computers and want to be able to support n-to-n source/sink setups (n number of constant all-zero multicast streams...).

2) I also saw the local WiFi network become crippled by the packet storm.  I see in the capture a packet rate of 137 per second.  I'm running a -n access point running OpenWRT 12.09 and have a solid 180Mbps+ connection, so I looked into a bit further and found:

a) multicast on wireless is effectively useless, or perhaps dangerous.  Multicast packets always use the lowest possible data rate on WiFi, which causes them to consume all available bandwidth and crowd out all other traffic:

https://dev.openwrt.org/ticket/10271

It appears that even running multicast on a wired network where wifi access points are connected can cause a takedown of the wifi networks if the wifi access points aren't filtering multicast.

b) there are some proposals for fixing this in a later revision of 802.11 but nothing we can use for a long time.

c) there are a bunch of people who have tried to use PA with RTP and some Raspberry Pis to distribute music and they've crashed and burned.  The Wiki should probably note that this shouldn't be attempted if there's a WiFi network involved.  Still, there is strong demand for this use case, if not RTP necessarily.*

d) Multicast on WiFi is so bad that it's more efficient to wrap the UDP in TCP and proxy it at the gateway:

http://wiki.openwrt.org/doc/howto/udp_multicast
  http://www.udpxy.com/index-en.html

In my testing, igmp snooping on OpenWRT (and presumably all of its derivatives) doesn't work yet.   I wonder if supporting udpxy's protocol in PA would make sense for the WiFi use case.  Perhaps smarter would be:

* there appears to be an evolving open source standard around the SlimProto

http://wiki.slimdevices.com/index.php/SlimProtoTCPProtocol
  http://wiki.slimdevices.com/index.php/SlimProtoDeveloperGuide
  https://code.google.com/p/squeezelite/source/browse/slimproto.c
  http://wiki.slimdevices.com/index.php/Design_of_new-streaming
  http://wiki.slimdevices.com/index.php/Synchronization

and the LMS implementation is said to have excellent synchronization which looks to be handled fairly simply in the perl code.  A PA sender and receiver that implemented a subset of squeeze might be neat to have - might even be usable with some of the hardware players.  Note: LMS (perl) is GPLv2 but slimsqueeze (c) is GPLv3 so direct code-reuse into PA is probably not possible.

Revision history for this message

Anton (feenstra) wrote on 2014-04-26:

#23

I just encountered this same symptoms today in my newly upgraded ubuntu (from LTS 12.04 to LTS 14.04): 100-150kB upload to 224.0.0.56 and my wifi down to less than 1Mb effective bandwidth.

There were a few updates today which seem to have triggered the behaviour, as I had no problems before the update.
But I cant seem to find the update history so I can't tell you which packages - it included a kernel update & reboot. I'm now running 3.13.0-24-generic.

Disabling rtp-send as per #5 works around the problem - and I'm not planning on streaming any audio any time soon.

Bug Watch Updater (bug-watch-updater) on 2014-06-11

Changed in pulseaudio (Debian):
status:	Incomplete → Fix Released

Bug Watch Updater (bug-watch-updater) on 2014-12-15

Changed in pulseaudio:
importance:	Unknown → High
status:	Unknown → Confirmed

Revision history for this message

Florian Fainelli (f-fainelli) wrote on 2015-05-01:

#34

I just stumbled upon this problem on an upgrade from 14.10 to 15.04 and this is absolutely killing everything on my network, completely crazy. Using paprefs and disabling the RTP sender did the trick though.

Would be really nice if this was not enabled by default, this completely kills WLAN networks which are probably how most people connect nowadadys...

Revision history for this message

Maksim Kachur (mcdebugger) wrote on 2015-05-08:

#35

The same here on two boxes.
My desktop is running Gentoo Linux and PulseAudio 5.0
My netbook is running Debian Jessie and PulseAudio 5.0

When I enable rtp sender even if I don't send any stream to RTP Sender sinc my Wi-Fi connection is getting flooded.

Revision history for this message

Solaris (kamshadman) wrote on 2015-08-21:

#36

I launched "Pulseaudio preferences" ---> under the tab "multicast/RTP", disabled "Multicast/RTP sender" .

problem solved!

Revision history for this message

Tom Hand (th6045) wrote on 2016-01-16:

#37

Download full text (8.1 KiB)

@Solaris That's not a fix, that's just disabling the feature.

This problem still exists. I'm on Ubuntu 15.10 and RTP send is flooding my network resulting in near total DoS.
This really needs to be resolved soon...

Example of packet storm:

21:23:48.763850 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.771958 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.780132 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.788273 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.796427 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.796461 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.804479 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.771863 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.780033 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.788235 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.796291 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.796337 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.804453 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.812512 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.820552 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.828657 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.836783 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.836849 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.844876 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.853086 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.861102 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.869134 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.869189 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.877130 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.885160 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.893190 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.901399 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.909441 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.909497 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.917538 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.925751 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.933814 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.941910 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.950011 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.950068 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.958090 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.966103 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.974125 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.982160 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.990252 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.990304 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.998288 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.006286 IP laptop.34779 > 224.0.0.56.46176: UDP, l...

@Solaris That's not a fix, that's just disabling the feature.

This problem still exists. I'm on Ubuntu 15.10 and RTP send is flooding my network resulting in near total DoS. 
This really needs to be resolved soon...

Example of packet storm:

21:23:48.763850 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.771958 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.780132 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.788273 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.796427 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.796461 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:48.804479 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.771863 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.780033 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.788235 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.796291 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.796337 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.804453 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.812512 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.820552 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.828657 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.836783 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.836849 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.844876 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.853086 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.861102 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.869134 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.869189 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.877130 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.885160 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.893190 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.901399 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.909441 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.909497 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.917538 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.925751 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.933814 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.941910 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.950011 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.950068 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.958090 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.966103 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.974125 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.982160 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.990252 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.990304 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:53.998288 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.006286 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.014295 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.022316 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.022362 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.030316 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.038344 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.046374 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.054622 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.062658 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.062694 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.070683 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.078725 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.086741 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.094757 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.102824 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.102869 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.110835 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.118777 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.126765 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.134779 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.142853 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.142910 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.150874 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.159059 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.167279 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.175354 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.183321 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.183352 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.191311 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.199334 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.207369 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.215507 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.223484 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.223511 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.231457 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.239429 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.247539 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.255704 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.255761 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.263824 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.271839 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.279915 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.287905 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.296111 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.296165 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.304186 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.312234 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.320274 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.328281 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.336299 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.336355 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.344343 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.352545 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.360652 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.368697 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.376741 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.376789 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.384836 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.392882 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.401123 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.409173 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.409226 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.734183 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.742281 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.742332 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.750402 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.758497 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.766561 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.774596 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.782753 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.782792 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.790864 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.798900 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292
21:23:54.806999 IP laptop.34779 > 224.0.0.56.46176: UDP, length 1292

Revision history for this message

markackerman8@gmail.com (markackerman8) wrote on 2016-02-23:

#38

Wow Thanks You

3 installs later just to find it creep into my system after a couple of days, and nothing on the web unless you know the phrase "flooded" the network.

And indeed using System Monitor it tricked me to believing it was other things, then finally who would have guessed - PulseAudio, after using it for 8 years,
indeed no Airtunes here, perhaps it started after installing Audacity - I don't know for sure, but kinda makes sense know.

indeed paprefs - Multicast/RTP - DISable "Multicast/RTP sender"
and/or gconf editor : pulseaudio -> modules -> rtp-send -Uncheck "enabled

How is this still a problem 5 years later - WOW

Thanks again

Revision history for this message

In freedesktop.org Bugzilla #44777, Marek Schimara (marek-schimara) wrote on 2016-04-06:

#39

This bug is still present in Fedora 23 x86_64 and pulseaudio-7.1-1
My machine was sending ~ 180KB/s to 224.0.0.56 until I unchecked "Enable Multicast/RTP sender" in paprefs.

For peace of mind, I ended up adding "unload-module module-rtp-send source=rtp.monitor" into /etc/pulse/default.pa

Revision history for this message

phonky (phonky) wrote on 2016-06-01:

#40

Confirming this bug too. I falsely blamed the provider for an unusable internet connection until I found out that it was my pulseaudio RTP module. BLUSH.

Well I wanted to be sending via RTP so disabling the module is just a temporary measure which makes me use Internet again LOL. But it surely is a bug.

Pulsaeaudio 7.1

Revision history for this message

kenn (whatnext) wrote on 2016-10-12:

#41

I am on Ubuntu 14.04.5 platform. I came across the same bug yesterday while trying to set up pulseaudio server on Windows to send audio from my Ubuntu laptop in local network and it rendered the home network unusable. It costed me hours to locate the pest. Dos attack triggered by pavucontrol, when I close it flooding diminishes.

I implemented the following workaround `pactl unload-module module-rtp-send`

Nobody's patched it for 8 years, so we have to live with this bug and no RTP server until my learning curve reaches a higher level to overcome it.

Revision history for this message

In freedesktop.org Bugzilla #44777, kenn (whatnext) wrote on 2016-10-13:

#51

I noticed the same bug in my system ( Ubuntu 14.04.5) while I was trying to set up pulseaudio server in Windows 10 over the local network. In my case network flooding occurs whenever I launch pavucontrol, upload traffics reaches up to 200kb/s and it reduced the local network unusable. When I close it the network attack diminishes.
I added `unload-module module-rtp-send` into `/etc/pulse/default.pa` to workaround the bug.

Revision history for this message

In freedesktop.org Bugzilla #44777, Freedesktop-u (freedesktop-u) wrote on 2016-11-01:

#52

I've also noticed this in the most up to data pulse versions from archlinux. I also cannot use a ttl of 1, as the router does not decrease the value when routing into wlan, as it has the same subnet. Neither does destination ip 24.0.0.1 help. From my side I have no chance to change the router config, because the internet is provided by someone else.

What works for me though is to stream the music directly to the destination via destination_ip=192.168.178.x

I could also add a menu in paprefs that'd also adress the ip directly, however this is more of a struggle because of the old gtk2 (if anyone here is following the mailing list). It would be highly appreciated to fix this bug in the module itself and reduce the payload somehow.

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2016-11-02:

#53

I read through the comments, and to me it looks like module-rtp-send doesn't have any flooding bug. The data rate of PCM audio is what it is, and the network hardware isn't always able to handle it. Multicast RTP is not enabled by default. If the user enables it, I don't know what we could possibly do to not "flood" the network.

Since this is a common problem for people, there is certainly room for improvement in the UI and documentation so that users don't get so surprised when things don't work.

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2016-11-02:

#54

Adding to my previous comment: it could be argued that the bug is that we transmit PCM audio instead of compressed audio. Adding support for compressed audio should help with the network stress. Does anyone volunteer to implement this?

Revision history for this message

In freedesktop.org Bugzilla #44777, TB2 (gt6) wrote on 2016-11-02:

#55

I know nothing about RTP, but from a user perspective, I have two questions:
1) Transferring a WAV file over the network goes faster than real time (in terms of the audio contained within). Why should the network struggle with uncompressed RTP audio, then?
2) Why are packets generated when nothing is played? If there is no audio activity in PA, there is no need to send any packets.
Apologies if this doesn't make sense, I'm talking purely as an end-user.

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2016-11-02:

#56

Sending a wav file means a TCP connection between two computers. TCP connections are the most common type of traffic, and the hardware is optimized accordingly. UDP multicast is different, and apparently network hardware is not necessarily as efficient with processing that protocol. Comment #9 seems to suggest that the wifi specification itself forces multicast to be inefficient, so it's not necessarily just the hardware's fault.

Starting from PA version 5.0, module-rtp-send should not generate traffic when nothing is playing (it can still be configured to play silence, but paprefs doesn't configure the module that way). If you observe different behaviour, please file a new bug and attach the output of "pactl list".

Revision history for this message

In freedesktop.org Bugzilla #44777, Freedesktop-u (freedesktop-u) wrote on 2016-11-03:

#57

You are right that this feature needs to be enabled first to make the bug rise. However I do not think that documentating this bug/behavior solves the problem. I do want to use music streaming, but I cannot do this as my router routes the traffic into the WLAN.

Lowering the rate is possibly not a good idea as it results in worse quality. The format is by default "s16be" about which I have no idea what a different format would help. I do not know if the data can somehow be compress further, because this would definitely be an idea, but I dont know the procols internal.

So the only left option is to solve the routing. For my personal setup there is no way to fix this on the router side, so the sender pulse module needs to take care of it. Using an ip as destination works perfectly and would be an option to use (which should be added to paprefs). However I tried that the last days and due to dhcp my receiver always gets a new IP and using hostnames would be a better idea.

But the module does not seem to support hostnames. So I am wondering if this could be fixed quite simple or needs a whole more work to do.

Another option would be to possibly create a port on the localhost and route that to the destination ip/name. And the kernel itself can do the name resolution. However I have no idea about that, but this could at least be a workaround to solve this issue.

Other opinions?

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2016-11-03:

#58

(In reply to freedesktop from comment #17)
> Lowering the rate is possibly not a good idea as it results in worse
> quality. The format is by default "s16be" about which I have no idea what a
> different format would help. I do not know if the data can somehow be
> compress further, because this would definitely be an idea, but I dont know
> the procols internal.

The data can certainly be compressed. I don't know if you've ever compared the sizes of mp3 and wav files. Typical compressed audio, when using a lossy codec, requires perhaps one tenth of the bandwidth that uncompressed audio requires, without too much effect on the audio quality.

> So the only left option is to solve the routing. For my personal setup there
> is no way to fix this on the router side, so the sender pulse module needs
> to take care of it. Using an ip as destination works perfectly and would be
> an option to use (which should be added to paprefs). However I tried that
> the last days and due to dhcp my receiver always gets a new IP and using
> hostnames would be a better idea.
>
> But the module does not seem to support hostnames. So I am wondering if this
> could be fixed quite simple or needs a whole more work to do.

Changing module-rtp-send to support hostnames doesn't sound terribly complicated.

Revision history for this message

In freedesktop.org Bugzilla #44777, Freedesktop-u (freedesktop-u) wrote on 2016-11-03:

#59

Sure mp3 would be way better. I just dont know how rtp works. I think its reasonable to use mp3 here. However I dont know how that works for streams and with pulse.

Fixing the compression method would be the better fix, however a specific ip/hostname would not hurt neither.

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2016-11-03:

#60

To my knowledge RTP can carry pretty much any format. You said on the mailing list that you want to use Kodi to receive the stream, and I don't know what Kodi supports, but I would guess that it supports many formats.

Don't get too excited about compressed audio, though. I'm not volunteering to implement it, and it's probably pretty complicated to integrate to PulseAudio.

In case someone is willing to take this task, the current "plan" (if you can call it a plan - it's all very fuzzy at the moment) is to use gstreamer to deal with the codecs, but in any case, please bring this topic up on the mailing list before spending too much time implementing it, so that there's an agreement about the design.

Revision history for this message

In freedesktop.org Bugzilla #44777, Tanu Kaskinen (tanuk) wrote on 2016-11-11:

#61

*** Bug 98649 has been marked as a duplicate of this bug. ***

Revision history for this message

Anton Alekseevich Bochkarev (antonalekseevich) wrote on 2016-12-06:

#42

This are upstream bug with Flooding packages to Network.
On pulseaudio 9.0 same problem, but upstream reqired to fix it up.

Distributive: ArchLinux.

Anton Alekseevich Bochkarev (antonalekseevich) on 2016-12-06

Changed in pulseaudio (Arch Linux):
importance:	Undecided → Unknown
status:	New → Unknown

Revision history for this message

Ka-Hing Cheung (kahing) wrote on 2017-01-31:

#43

just discovered this on 16.04, pactl unload-module module-rtp-send "fixed" it

Revision history for this message

dgtlmoon (dgtlmoon) wrote on 2017-03-07:

#44

same here :( had to restart pulseaudio

Revision history for this message

dgtlmoon (dgtlmoon) wrote on 2017-03-07:

#45

ubuntu 16.04

Revision history for this message

In freedesktop.org Bugzilla #44777, Piotr Gorski (k-piotr) wrote on 2017-05-11:

#62

All problems with RTP module flooding network, Wifi are caused by lack of IGMP support in rtp_send module.

When pulseaudio with rtp_recv module is started proper IGMPv2 signalling works like it should:

root@orangepione:~# tshark -i eth0 -Y "igmp"
Capturing on 'eth0'
117 6.950723148 192.168.254.141 -> 239.255.1.56 IGMPv2 46 Membership Report group 239.255.1.56
177 10.430705605 192.168.254.141 -> 239.255.1.56 IGMPv2 46 Membership Report group 239.255.1.56
215 13.660683494 192.168.254.141 -> 239.255.1.56 IGMPv2 46 Membership Report group 239.255.1.56

Pulseaudio creates Multicast group (I don't use default group). As IGMP signalling is OK - IGMP capable switches enable that multicast group only on ports that need it.

If pulseaudio is configured with rtp_send module - there is no IGMP signalling.

Looking at code of module-rtp-recv.c we can find:

mr4.imr_multiaddr = ((const struct sockaddr_in*) sa)->sin_addr;
r = setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mr4, sizeof(mr4));

IP_ADD_MEMBERSHIP tells kernel to join multicast group.

There is no such command is module-rtp-send.c

It needs fixing ASAP

Bug Watch Updater (bug-watch-updater) on 2017-05-14

Changed in pulseaudio (Arch Linux):
importance:	Unknown → High
status:	Unknown → Confirmed

Revision history for this message

Mark Stosberg (markstos) wrote on 2017-11-15:

#46

I ran into this flooding today on Ubuntu 17.10. This "fixed" it, at least temporarily:

pactl unload-module module-rtp-send

Revision history for this message

alex dekker (ubuntu-ale) wrote on 2017-12-05:

#47

killall pulseaudio didn't fix it, but:

# chmod 0600 /usr/lib/pulse-10.0/modules/module-rtp-send.so

followed by killall pulseaudio again did and this will doubtless work until the package is updated.
I have no idea why this issue popped up today. I haven't made any changes to my sound settings for a while and the timestamp on ~/.gconf/system/pulseaudio/modules/rtp-send is July 2012.

Revision history for this message

elhoir (jfarroyo82) wrote on 2017-12-07: Re: [Bug 411688] Re: pulseaudio floods network with multicast packets

#48

Download full text (11.0 KiB)

please tell me "0" rights to "others" group does not affect root account.....

________________________________
De: <email address hidden> <email address hidden> en nombre de alex dekker <email address hidden>
Enviado: martes, 5 de diciembre de 2017 18:03:58
Para: <email address hidden>
Asunto: [Bug 411688] Re: pulseaudio floods network with multicast packets

killall pulseaudio didn't fix it, but:

# chmod 0600 /usr/lib/pulse-10.0/modules/module-rtp-send.so

followed by killall pulseaudio again did and this will doubtless work until the package is updated.
I have no idea why this issue popped up today. I haven't made any changes to my sound settings for a while and the timestamp on ~/.gconf/system/pulseaudio/modules/rtp-send is July 2012.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/411688

Title:
pulseaudio floods network with multicast packets

Status in PulseAudio:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed
Status in pulseaudio package in Arch Linux:
  Confirmed
Status in pulseaudio package in Debian:
  Fix Released

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: 000...

please tell me "0" rights to "others" group does not affect root account.....

________________________________
De: bounces@canonical.com <bounces@canonical.com> en nombre de alex dekker <411688@bugs.launchpad.net>
Enviado: martes, 5 de diciembre de 2017 18:03:58
Para: jfarroyo82@hotmail.com
Asunto: [Bug 411688] Re: pulseaudio floods network with multicast packets

killall pulseaudio didn't fix it, but:

# chmod 0600 /usr/lib/pulse-10.0/modules/module-rtp-send.so

followed by killall pulseaudio again did and this will doubtless work until the package is updated.
I have no idea why this issue popped up today. I haven't made any changes to my sound settings for a while and the timestamp on ~/.gconf/system/pulseaudio/modules/rtp-send is July 2012.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/411688

Title:
  pulseaudio floods network with multicast packets

Status in PulseAudio:
  Confirmed
Status in pulseaudio package in Ubuntu:
  Confirmed
Status in pulseaudio package in Arch Linux:
  Confirmed
Status in pulseaudio package in Debian:
  Fix Released

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/pulseaudio/+bug/411688/+subscriptions

Revision history for this message

In freedesktop.org Bugzilla #44777, Gitlab-migration (gitlab-migration) wrote on 2018-07-30:

#63

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/505.

Revision history for this message

Tecfu (help-b) wrote on 2018-09-25:

#49

This ticket was opened 9 years ago. Bug still exists in Ubuntu 16.04.05.

/etc/pulse/default.pa
```
load-module module-null-sink sink_name=rtp
load-module module-rtp-send source=rtp.monitor
set-default-sink rtp
```

This feature still floods the network with packets. Disabling it isn't a fix, its merely opting out of a broken feature.

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2018-10-01:

#50

The bug is open with upstream. If you have any comments about it then the best place to discuss is with upstream:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/505

Bug Watch Updater (bug-watch-updater) on 2019-01-03

Changed in pulseaudio:
status:	Confirmed → Unknown
Changed in pulseaudio (Arch Linux):
status:	Confirmed → Unknown

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2019-01-07:

#64

Closed for Ubuntu since the bug is closed upstream. If you feel this is incorrect then please comment upstream (https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/505) and then here.

Changed in pulseaudio (Ubuntu):
status:	Confirmed → Won't Fix

Ubuntu
pulseaudio package

pulseaudio floods network with multicast packets

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

	Status	Importance	Assigned to
PulseAudio	Unknown	High	freedesktop-bugs #44777
pulseaudio (Arch Linux)	Unknown	High	freedesktop-bugs #44777
pulseaudio (Debian)	Fix Released	Unknown	debbugs #522598
pulseaudio (Ubuntu)	Won't Fix	Low	Unassigned

Ubuntupulseaudio package

pulseaudio floods network with multicast packets

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
pulseaudio package