[ale] md5sum weirdness on firefox -- SOLVED

[Joe Bayes]

Hi again,

Some of you may remember my problem with md5sum and firefox from about
three weeks ago. Well, I figured out the problem. As usual, there were
two different things going on, each obfuscating the solution. 

Problem 1: "md5sum /usr/bin/md5sum" gives a different checksum on
  Monday than it does on Tuesday. 

Solution 1: No, I wasn't rooted. Fedora has started using a program
  called "prelink". It modifies the binaries by linking them before
  runtime. So, if you want to do a checksum on one of these
  executables, run "prelink --undo filename" before running the
  md5sum.

Problem 2: "md5sum firefox-1.5.0.9-3.fc6.i386.rpm" gives me the wrong
  checksum, even when I download it several times and several
  different ways. When I upload the "bad" binary to a third computer,
  the md5sum checks out fine. (!!!)  
  "md5sum firefox-1.5.0.10-5.fc6.i386.rpm" (note the version change)
  gives the proper checksum. 

Solution 2: No, there's nothing wrong with md5sum: it was my
  router. When my router does its own peculiar version of NAT, it
  replaces 216.86.915.37 with 192.168.0.2 in incoming packets. In
  outgoing packets, it reverses the process. Apparently it does this
  substitution in packet data as well as in the routing information,
  and firefox-1.5.0.9-3.fc6.i386.rpm just happened to contain (the
  encoded representation of) 216.86.195.37 somewhere in the data. 

  I was able to (finally) sneak the data in by uuencoding it and
  compressing it, thereby hiding the bit string that was triggering
  the problem.

A FAQ page for BitTorrent (which is what clued me in to the solution)
claims that this happens approximately once in every 4G of data. (This
is the reason why some torrents hang at 99.9%).

Somebody suggested that the problem was that my router was mangling my
data, and I said, "No, 'cause it would have to be mangling it the same
way every time, and then it would have to automagically un-mangle it
on the way out, and that's fantastically unlikely". Well, I guess I
was wrong: it's not all that fantastically unlikely after all. 

Special thanks to Jerry Yu, timothy at meanor.net, and everybody else who
helped me out with this problem. 

Joe

--
Joe Bayes -- jbayes at spoo.mminternet.com