Botnet or Pulseaudio

The other day I was sitting at home when I realized that my network switch was going crazy. The switch in question is a gigabit switch that is connected to my home server (which is my home’s gateway device — the one connected to the modem), to a wireless router, and to a desktop machine that acts as a media box (it’s connected to a TV and stereo system). By “going crazy” I mean that all the lights were flashing as fast as they could. There is a light for each connected device, and when it flashes it means that that device is either sending or receiving data — meaning that in this case packets were going to or from my server, my media box, and my wireless router (which by proxy means my laptop, my phone, my wife’s phone, etc) apparently about as fast as possible. Recently there have been some high profile DDOS attacks by botnets of unprecidented size. “Am I part of a botnet?”, I wondered. “Did I make some serious security mistake, despite generally being much more careful than average about security?”.

I’m no networking expert, but I quickly reached for wireshark, which told me that my laptop was sending thousands of UDP packets to 224.0.0.56. I tried to do a reverse DNS lookup on this unknown address, but to no avail! A quick web search on the address, though, told me that it’s actually a multicast IP address. So these packets weren’t going out to some mystery computer on the internet, but they were multicast and only going within my LAN. That explained why all computers had traffic — multicast packets are routed to all of them. So I turned to my laptop to do some netstat, revealing that these thousands of packets were coming from… pulseaudio!

It turns out that a couple days previously I had been playing with pulseaudio settings with paprefs, and had turned on an RPC Multicast virtual output sink. I figured this would give me an optional broadcast audio output, which it did. But apparently even when it’s not receiving any audio, the virtual device spams the network with a barrage of multicast traffic. It seems this is just an issue with pulseaudio that has been around for years and that nobody cares to fix. So clearly I needed to turn it off. As it happens, it took me a long time to turn off — paprefs was somehow not able to turn off the setting that it had turned on. I tried seeing if it was writing to any files with strace, but it wasn’t. But eventually I found that paprefs is backed by gconf, and I was able to toggle the setting off with gconf-editor.

So I’m happy that my computers weren’t part of a botnet after all (as far as I know!), and that I was able to solve a little network mystery.

The End.