How My Printer Caused Excessive Syscalls and UDP Traffic

How My Printer Caused Excessive Syscalls and UDP Traffic(zinascii.com)

90 points by rzezeski 11 years ago | 16 comments

cesarb 11 years ago |

At least all he had was excessive syscalls.

At work, we had a problem where a computer was spamming the network with DHCP requests. It ended up physically locking us out; the embedded system which controls the card reader and unlocks the door locked up due to the load. I had to use an alternative way to get in, isolated the maglock, and later power-cycled the embedded system.

Needless to say, we enabled storm control on the switch after that.

tjohns 11 years ago | |

You might want to put your security system and other infrastructure hardware on a separate VLAN.

Not only does that help prevent stuff like this, it turns out that a lot of embedded hardware isn't that great from a network security perspective.

cesarb 11 years ago | | |

We didn't even have VLANs enabled on the switch back then.

And even then, the storm control is useful; the same broadcast storm also made the office wireless unusable (most APs use a basic rate for broadcast and multicast).

akersten 11 years ago |

Yet another reason to cordon off printers and other mystery meat devices to their own special VLAN...

joshu 11 years ago | |

I feel like this couldn't happen soon enough. All those mysterious networked AV devices (why does my TV want to be on ethernet anyway? It's not even a smart TV) and their mysterious poorly written firmware.

jmgrosen 11 years ago |

This reminded me of a Reddit comment I read just earlier today about overzealous mDNS packets causing battery life issues on Android: https://www.reddit.com/r/Android/comments/2ler3t/maybe_the_r...

Funny that these happened to appear on the same day :)

tedunangst 11 years ago |

I'll point out that the original vmstat output also revealed 3000 interrupts per second, in the column right next to syscalls. Many times it can be faster to look around at the high level instead of immediately diving deep. In this case, checking to see which device was causing the interrupt storm would have led to "something on the network" pretty quickly.

userbinator 11 years ago |

Is mDNS really so useful? Of all the people I know who know about it, everyone has disabled it when possible due to all the useless network traffic it produces.

Apparently Canon's wireless printers are well known for doing mDNS floods:

http://digitalhome.ca/forum/showthread.php?t=148153

http://forums.anandtech.com/archive/index.php/t-2171044.html

glitch 11 years ago | |

mDNS has utility in small networks for your average Joe. In these circumstances (1) it shouldn't be a problem, (2) it shouldn't flood (there's logarithmic decay and there actually has been thought put into this), (3) names are discoverable without relying on anything else, (4) and it does its job in being the mechanism for DNS-SD to piggyback on so that services can be discovered automatically. Being independent of other services working or not — e.g., DHCP, (unicast) DNS — means "it just works", even if other network services fail.

There is a beauty in the ability to just have all of your computers, printers, and peripheral devices otherwise plug into a switch (without any additional network service equipment — no router/dns/dhcp multi-combo device added in the mix) and that everything just ends up working. Link-local addressing takes care of IPs, mDNS takes care of names, and DNS-SD through mDNS takes care of automatic service advertisement — "Hey, I'm a printer, use me if ya wanna!"

Further, failure of proper mDNS implementation in a device (perhaps resulting in malformed packets or over-zealous flooding) is just a failure of that device's design, not mDNS per se.

Having said that, still... yes, I think the home/SOHO router/switch/access-point/dns/dhcp multi-combo device should handle DNS-SD registrations and DNS, and that mDNS shouldn't be needed.

In medium/large networks (those actually managed by someone putting on an IT hat), it's perhaps not as appropriate, but still shouldn't be a problem assuming everything is subnetted with mDNS in mind. Of course, name resolution is handled by unicast DNS, and with regard to service discovery in this context, someone manages the DNS-SD records on the unicast DNS server so you don't need mDNS to be the mule for DNS-SD to ride on in those circumstances.

voltagex_ 11 years ago | | |

>someone manages the DNS-SD records on the unicast DNS server so you don't need mDNS to be the mule for DNS-SD to ride on in those circumstances.

Are you talking about TXT records for services or something like that? I thought that most of the consumer level tools (for adding printers) were only looking for records via mDNS.

That said, in $CURRENTJOB, network printers are found via whatever the current version of NETBIOS is called - I don't think I've seen any mDNS traffic around.

bensummers 11 years ago | |

I find mDNS very useful for our development VMs: http://bens.me.uk/2013/multicast-dns-and-development-virtual...

Instead of hacking your /etc/hosts file, just let the VM publish relevant DNS entries using mDNS.

rasz_pl 11 years ago |

What were teh effects? How did the author notice? Was his server lagging? his OSX machine? If would be pretty awesome if you could dos MACs with 250KB/s flood.

rzezeski 11 years ago | |

That's a good question. I should have mentioned that in the post perhaps. The reason I initially ran vmstat was just to make sure my dev machine was "zeroed out". Recently my kernel builds had taken twice the time as normal and I wasn't sure why. That's when I noticed this. It turns out this had no significant effect on my build times but was rather an effect of a different change I made weeks prior. I also noticed no ill effects on my laptop that I recall.