how can a downloading a specific file crash a router?

July 7, 2007 2:49 PM

how can the downloading of a specific file crash a router? a few years back, at work, our router started crashing every few minutes. turns out one of my coworkers was trying to download a PDF from an FTP site. in the middle of the download the router would just stop working.

he tried downloading it from various sources: a website, via email attachment, etc: if that specific file's bits came through our router, it would bonk. this makes me think of the nam-shub from Stephenson's _Snow Crash_. can anyone shed light on how this may've happened?

how can a specific sequence of bits take down the node that is transmitting the sequence?

posted by k7lim to technology (9 comments total)

What make and model of router?
posted by signalnine at 2:53 PM on July 7, 2007

Lots of network hardware has some very very badly written software running on it. Even the high end things have all sorts of horrible bugs actually. For example if you go into a busy IRC channel and write

DCC SEND C:////////////////////////////////////////////////////

Lots of people will generally disconnect. (And on Freenode you will get banned from the server temporarily.)

As the devices have gotten more complex and had to handle more and more features and "security" procautions the software quality and performance has been kept at a sort of, barely functioning level. I used to have an ADSL modem that would drop all of its connections if you opened more than 200 TCP connections at once.

Basically, network hardware is really quite awful in many ways, but works fairly well most of the time.
posted by public at 3:04 PM on July 7, 2007

We used to have a router that would crash if a file larger than a certain size was FTPed.
posted by bottlebrushtree at 3:10 PM on July 7, 2007

It can happen. The right string embedded in a data stream will cause a modem to disconnect.
posted by Leon at 3:35 PM on July 7, 2007

+++
ATH0
posted by IronLizard at 3:48 PM on July 7, 2007

Though most modems required a pause between the + and commands because a file transfer/page containing these wouldn't pause, thereby canceling the command.
posted by IronLizard at 3:50 PM on July 7, 2007

Router != Modem. Presumably this being an office connection they aren't using a dialup modem for their connectivity.

And that trick hasn't been very effective against modems for quite a while anyway.
posted by public at 4:00 PM on July 7, 2007

It's probably a stupid bug in the router's NAT handling, and the way it rewrites active FTP sessions to work through it.

Active FTP means the client says "I've opened a server on $ip:$port, now send it $file" -- except in a NATed system that IP address will be wrong (generally an rfc1918 private address; 192.168.*.*, 10.*.*.*, etc), so it:

1. Rewrites the command to tell the FTP server to use the router's IP address, and possibly a different port
2. Forward packets being sent to that address/port to where the client expects it

If the rewriting or parsing goes wrong, it might end up overwriting the buffer the packet is stored in, corrupting other data, or otherwise end up in some undefined state it can't recover from. Since there's a lot of pressure to be as fast and frugal as possible, this code can be quite ugly, and if you're hiring sub-par programmers to do it, or skimping on your QA departments.. *boom*. It's fairly common to find fixes for these things in firmware updates.

IRC DCC and various other protocols have much the same sort of problem; the packets need to be analysed and rewritten to work properly over NAT.
posted by Freaky at 8:45 PM on July 7, 2007

Lots of reasons (like the aboved mentioned). I had a linksys that crashed if it tried to transfer data using UDP instead of TCP. The only fix was to rollback the firmware. This is incredible for a mainstream device that probably sold by the millions.
posted by damn dirty ape at 10:22 PM on July 7, 2007