

How My Printer Caused Excessive Syscalls and UDP Traffic - rzezeski
http://zinascii.com/2014/how-my-printer-caused-excessive-syscalls.html

======
cesarb
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
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
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
Yet another reason to cordon off printers and other mystery meat devices to
their own special VLAN...

~~~
joshu
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
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...](https://www.reddit.com/r/Android/comments/2ler3t/maybe_the_reason_why_nexus_5_owners_are_still/clu6qct)

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

------
tedunangst
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
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://digitalhome.ca/forum/showthread.php?t=148153)

[http://forums.anandtech.com/archive/index.php/t-2171044.html](http://forums.anandtech.com/archive/index.php/t-2171044.html)

~~~
glitch
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_
>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.

~~~
glitch
For a simple DNS-SD setup on unicast DNS, yes, it's basically a combination of
PTR and TXT records. See [http://www.dns-
sd.org/serversetup.html](http://www.dns-sd.org/serversetup.html) for more
information.

For example, in one network, multicast was completely disabled — no mDNS
happening there — and so on our local (unicast) DNS server (BIND on a 'BSD),
we added DNS-SD entries (PTR + TXT records) for printers (to a CUPS print
server with Active Directory authentication) which gave all the iOS devices
AirPrint capability to all the printers on the network (even AirPrint to old
dot-matrix printers), entries for Apple TV/AirPlay, etc. Apple calls it "Wide-
Area Bonjour" and it works with Macs and iOS devices just fine — it's Bonjour
with no mDNS involved (more specifically, it's just DNS-SD with a unicast DNS
server).

In a sense (and completely avoiding all of the details and particulars of the
matter here, because that opens up a whole can of worms and a much longer
discussion), mDNS is basically supposed to be the modern IETF Internet
Standards branded replacement for the name service aspect of NetBIOS (and
other local network name service protocols). See also
[http://lwn.net/Articles/252323/](http://lwn.net/Articles/252323/) ... Also,
in a sense, Zeroconf (an umbrella term which includes IPv4 link local
addressing + mDNS + DNS-SD) is replacement for SLP ... and SSDP & UPnP in a
sense too (although they're not directly comparable concepts)... Read
[http://www.zeroconf.org/zeroconfandupnp.html](http://www.zeroconf.org/zeroconfandupnp.html)
for a better explanation on the UPnP side of things... (Again, using a really
vague phrase "in a sense" here and glossing over the details and doing a hand-
wavy gesture.) There are different matters of naming, service discovery, and
higher layer protocols — and drawing lines of correlation aren't always direct
nor as clear cut as some would like.

~~~
kawouli
A service instance is a combination of an SRV record containing the service
hosts name and port and a TXT record containing meta-information (key=value
pairs). Services instances are found via PTR records.

For HTTP services in a browse domain called example.com, you'd query for
_http._tcp.example.com PTR records and get back a list of instance names such
as HN._http._tcp.example.com. If you then wanted to connect to the "HN" HTTP
service you'd then lookup the SRV and TXT records at
HN._http._tcp.example.com.

For anyone interested, dns-sd.org hosts some example services — try `dig -t
ptr _http._tcp.dns-sd.org` and go from there.

~~~
glitch
Yep! I forgot to mention the SRV records for some odd reason.

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

