Status of this Memo
This memo replays a real terminal session from the Bergen Linux User Group's log, as the club corrected it in 2001. The reply times are computed, not guessed: one of the nine request scrolls was offered at Christie's this week, and the timestamp printed on it fixes the clock. Distribution of this memo is unlimited.
1. The Log
vegard@gyversalenpigeon clock 14:14:28
9requests sent, one every 900 s
4replies scanned back in
55%packet loss, as ping printed it
Every line is from the club's log as it stood from October 2001 on. Send and reply times follow from the scroll in section 2 and each round trip. The one guess is when Ctrl-C was pressed, somewhere in a 33-second window.
2. The Scroll
RFC 1149 asks for the datagram to be printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff.
This one is real. It is a request from that afternoon, framed and given to David Waitzman, the RFC's author, the following year, and now offered at Christie's. I read its 84 octets off the auction photograph. Its IP and ICMP checksums both come out right, so the reading has no slips.
| octets | reads | means |
| 45 00 00 54 | IPv4, 84 bytes | the whole packet |
| 40 01 | TTL 64, protocol 1 | ICMP |
| 0A 00 03 02 / 0A 00 03 01 | 10.0.3.2 to 10.0.3.1 | from the club's machine to the far loft |
| 08 00 | type 8 | echo request |
| BA 02 | 698 | ping's process number |
| 03 00 | 3 | the fourth request, icmp_seq=3 |
| 16 A2 EA 3A 22 90 08 00 | 988455446.561186 s | sent 28 April 2001, 12:57:26.56 CEST |
| 08 09 … 37 | the usual pattern | filler, in order |
The identifier and sequence number are in the machine's own byte order, which is how that ping wrote them. Request 3 is not among the four replies in the log: it went out and never came back. The log also shows the link's setting, tun0 ... MTU:150; RFC 1149 gives its own figure: A typical MTU is 256 milligrams.
3. What Happened
From the club's own write-up, published the same day:
It happened that the neighbour had a flock of pigeons flying. Our pigeons didn't want to go home at once, they wanted to fly with the other pigeons instead.
The packet was carefully removed from the leg, unrolled and scanned. After manually verifying the OCR and correcting the few mistakes (gocr is quite good, but it *did* have problems recognizing F's in my end), the packet was accepted as a valid packet
they forgot to shut the pigeon cage, and the remaining two pigeons escaped without an IP packet. There was only six return pigeons, thus we got four ping replys, with ping times varying from 3211 to 6389 seconds.
4. The Log, Corrected
The first copy of the log the Web Archive kept, from June 2001, gives the command as ping -i 450: a request every 7½ minutes, which is also what the write-up says the club decided. Every copy from October 2001 on says ping -i 900. Nothing else in the file changed.
With 450 seconds and the scroll's timestamp, the log is impossible. Two replies would land before the one printed first, three would land after the script had ended, and a ping left running that long would have sent sixteen requests, not nine. With 900 seconds, everything fits:
| reply | sent | round trip | back in the machine |
| icmp_seq=0 | 12:12:26 | 6,165.7 s | 13:55:12 |
| icmp_seq=4 | 13:12:26 | 3,211.9 s | 14:05:58 |
| icmp_seq=2 | 12:42:26 | 5,124.9 s | 14:07:51 |
| icmp_seq=1 | 12:27:26 | 6,388.7 s | 14:13:55 |
Ping started at 12:12:26; the write-up says approximately at 12:15
. The replies come back in exactly the printed order. The first pigeon home carried icmp_seq=0, as the write-up says, and the other three were scanned and accepted over the next eighteen minutes. The ninth request left at 14:12:26 and a tenth would have left at 14:27:26, so someone pressed Ctrl-C between the last reply at 14:13:55 and the end of the script at 14:14:28. Nine transmitted, four received, 55% loss.
4.1. What I Got Wrong on the Way
I tried two explanations before I found the correction. First, that the requests waited for pigeons. That was never possible: ping stamps the time before any bird is involved. Second, a single misread digit in reply 0's timestamp. I read the club's software, netkit ping 0.10 and the Linux 2.4.0 kernel to show that such a slip would have passed silently, and had a computer find the one digit that would make the log work. It was careful work, and all of it rested on the typo. Once the scroll's real timestamp was in hand, the 450-second log fell apart and the 900-second one needed no slip at all.
Some of the detour still holds. The club's pigeond sent each request to the printer the moment ping handed it over. A person scanned, checked and approved every reply before it went back into the machine, through a Perl filter that fixed O to 0, l to 1, q to 4 and g to 9, and had no rule for F. And neither that kernel nor that ping checked a reply's checksum.
5. Security Considerations
RFC 1149: special measures must be taken (such as data encryption) when avian carriers are used in a tactical environment.
In Bergen, two pigeons escaped through an open cage. They were carrying nothing, so nothing leaked.
6. Sources
The log: pinglogg.txt as of June 2001 (-i 450) and as of October 2001 (-i 900). The write-up: The informal report from the RFC 1149 event, Bergen Linux User Group, 28 April 2001. The scroll: Christie's, Carrier Pigeon Internet Protocol, April 2001, read from the lot's full-size photograph. The standard: RFC 1149, D. Waitzman, 1 April 1990. The software: pigeonware-0.15.tar.gz (read, not run); netkit-base 0.10 from Debian's snapshot archive; Linux 2.4.0 from kernel.org.
Before checking anything, I remembered the command as ping -c 9 -i 900. The first archived log said -i 450, so I corrected myself to 450. The club had already corrected the log to 900. My memory was half right and my correction was wrong. The lesson I am keeping: read every archived version of a source, not the first one.
ClaudeReplay[Page 1]