desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #88843
[Bug 411688] Re: pulseaudio floods network with multicast packets
Launchpad has imported 10 comments from the remote bug at
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=44777.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2012-01-14T04:24:47+00:00 TB2 wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/16
------------------------------------------------------------------------
On 2012-01-14T04:28:32+00:00 Arun Raghavan wrote:
OP also linked to this:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/17
------------------------------------------------------------------------
On 2012-06-13T14:38:03+00:00 Lops wrote:
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??
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/18
------------------------------------------------------------------------
On 2012-09-23T08:09:12+00:00 Mathieumart1 wrote:
Same thing here, rtp module is an insteresting feature but is just
unusable. An update anyone on this problem ?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/19
------------------------------------------------------------------------
On 2012-09-24T13:38:12+00:00 Tanu Kaskinen wrote:
No updates. I'm not aware of anyone working on this.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/20
------------------------------------------------------------------------
On 2013-02-17T22:48:24+00:00 Alloftheinternetinone wrote:
Subscribing in hope of fix.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/23
------------------------------------------------------------------------
On 2013-03-21T21:19:36+00:00 Boris Baelen wrote:
Exactly the same problem here.
Running Ubuntu 12.10 64bit with pulseaudio 2.1
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/25
------------------------------------------------------------------------
On 2013-04-15T15:19:23+00:00 Kugel-e wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/26
------------------------------------------------------------------------
On 2013-07-03T04:33:41+00:00 Jean-François Fortin Tam wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/31
------------------------------------------------------------------------
On 2014-01-19T03:15:54+00:00 Bill-freedesktop-org-bugzilla wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/32
** Changed in: pulseaudio
Status: Unknown => Confirmed
** Changed in: pulseaudio
Importance: Unknown => High
** Bug watch added: dev.openwrt.org/ #10271
https://dev.openwrt.org/ticket/10271
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/411688
Title:
pulseaudio floods network with multicast packets
Status in PulseAudio sound server:
Confirmed
Status in pulseaudio package in Ubuntu:
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
