The solver should download “trips.pcap” using the download link. The first step is to figure out what kind of file this is, if it’s not clear from the file extension. A Google search for “pcap” would return results indicating that this is a pcap packet capture file.

Alternatively, we may use the Unix file command to identify the file type:

$ file trips.pcap
trips.pcap: tcpdump capture file (little-endian) - version 2.4 (raw IP, capture length 65535)

The tcpdump command line tool can be used to decode the file, or it can be opened in Wireshark. Using tcpdump to decode it would result in the following output:

$ tcpdump -r trips.pcap
reading from file trips.pcap, link-type RAW (Raw IP)
-13:00:00.00000 IP mail37.mxpath.net.discard > fe1-0.soesr3.nyc9.maint.ops.us.uu.net.8: UDP, length 11
-13:00:00.00000 IP 88.84.189.220.8 > 10-160-58-66.gci.net.3: UDP, length 14
-13:00:00.00000 IP 149.238.2.175.10 > 198.154.25.255.5: UDP, length 12
-13:00:00.00000 IP 103.238.104.0.3 > 103.243.40.0.discard: UDP, length 15
-13:00:00.00000 IP a.0.135.59.108.servpac.com.2 > c-50-131-229-144.hsd1.ca.comcast.net.5: UDP, length 14
-13:00:00.00000 IP 100.9.214.0.echo > ool-44c09340.dyn.optonline.net.6: UDP, length 10
-13:00:00.00000 IP 85.90.227.224.4 > pool-100-12-116-128.nycmny.fios.verizon.net.3: UDP, length 11
11:00:00.000000 IP 160.35.80.1.6 > 223.223.176.0.8: UDP, length 13
11:00:00.000000 IP 193.37.246.254.1 > 193.37.246.254.6: UDP, length 15
11:00:00.000000 IP 223.255.192.0.5 > 64.201.212.0.echo: UDP, length 13

This is a sequence of captured UDP packets. Running tcpdump again with the -X option (to see the contents of the packets) and the -vv option (to check the packet UDP checksums) reveals that the characters in the packet payloads are all X characters (0x58) and spaces (0x20), resulting in incorrect checksums:

$ tcpdump -r trips.pcap -X -vv
reading from file trips.pcap, link-type RAW (Raw IP)
-13:00:00.00000 IP (tos 0x0, id 0, offset 0, flags [none], proto UDP (17), length 39)
    mail37.mxpath.net.discard > fe1-0.soesr3.nyc9.maint.ops.us.uu.net.8: [bad udp cksum 0xbb53 -> 0x7414!] UDP, length 11
        0x0000:  4500 0027 0000 0000 0011 40a6 42b9 a305  E..'......@.B...
        0x0010:  ce40 c621 0009 0008 0013 bb53 5858 5858  .@.!.......SXXXX
        0x0020:  5820 5858 5858 58                        X.XXXXX
-13:00:00.00000 IP (tos 0x0, id 0, offset 0, flags [none], proto UDP (17), length 42)
    88.84.189.220.8 > 10-160-58-66.gci.net.3: [bad udp cksum 0x0f49 -> 0x9d0f!] UDP, length 14
        0x0000:  4500 002a 0000 0000 0011 c24e 5854 bddc  E..*.......NXT..
        0x0010:  423a a00a 0008 0003 0016 0f49 5858 5858  B:.........IXXXX
        0x0020:  5820 5858 5858 5858 5858                 X.XXXXXXXX
...

The next step is to figure out what characters the Xs in the packet payloads should be, based on packet metadata. For each packet, we know the timestamp when it was received, the source and destination IP addresses, the source and destination port numbers, and the payload length.

The timestamps in the tcpdump look suspicious—why do many of them have negative hours? Running tcpdump again with fuller timestamp formatting (the -tttt option) would result in the following output (we’ll also pass -n now to skip the IP DNS lookups):

$ tcpdump -r trips.pcap -tttt -n
reading from file trips.pcap, link-type RAW (Raw IP)
1914-05-15 -13:00:00.00000 IP 66.185.163.5.9 > 206.64.198.33.8: UDP, length 11
1926-05-15 -13:00:00.00000 IP 88.84.189.220.8 > 66.58.160.10.3: UDP, length 14
1928-10-16 -13:00:00.00000 IP 149.238.2.175.10 > 198.154.25.255.5: UDP, length 12
1930-04-07 -13:00:00.00000 IP 103.238.104.0.3 > 103.243.40.0.9: UDP, length 15
1935-01-13 -13:00:00.00000 IP 108.59.135.0.2 > 50.131.229.144.5: UDP, length 14
1957-07-17 -13:00:00.00000 IP 100.9.214.0.7 > 68.192.147.64.6: UDP, length 10
1964-02-08 -13:00:00.00000 IP 85.90.227.224.4 > 100.12.116.128.3: UDP, length 11
1972-02-21 11:00:00.000000 IP 160.35.80.1.6 > 223.223.176.0.8: UDP, length 13
1982-08-29 11:00:00.000000 IP 193.37.246.254.1 > 193.37.246.254.6: UDP, length 15
1995-02-21 11:00:00.000000 IP 223.255.192.0.5 > 64.201.212.0.7: UDP, length 13

These are some old packets! The negative hours field may be confusing, it indicates that the timestamp is actually from the previous day (e.g., 1914-05-15 -13:00:00.00000 is actually a timestamp from 1914-05-14). This is a consequence of how Unix timestamps are used to represent dates before 1970-01-01.

Looking up the IP addresses in an IP geolocation database (e.g., https://geoiptool.com) will reveal locations around the world. For example, the 1964-02-07 packet has a source IP of 85.90.227.224, which geolocates near London, and it has a destination IP of 100.12.116.128, which geolocates to New York City.

The combination of February 7, 1964, a starting point of London, and an ending point of New York City, suggests The Beatles’ first trip to the United States. The payload string “THE BEATLES” has a length of 11 bytes, which matches the missing UDP payload length, the pattern of Xs and spaces, and the checksum. Each packet has metadata like this that clues a famous trip.

After solving each of the packets in this way, we know the packet payloads. If we now reorder the packets by their source port numbers, and index into the packet payloads by their destination port numbers, we get the answer PIGEON LAKE.