SC_TBITPMTUD(1)

💖 SC_TBITPMTUD 💖

okay so bestie, you know the drill — this is the sc_tbitpmtud manual page, and it's giving very serious network-nerd energy. sit down, grab a boba, we're testing whether the internet behaves. 🧚

---

✨ NAME ✨

sc_tbitpmtud — a scamper driver that tests systems to see if they actually respond to ICMP packet too big messages. no cap.

---

🌸 SYNOPSIS 🌸

sc_tbitpmtud [-r] [-a address-file] [-c completed-file]
             [-l limit-per-file] [-m maximum-transmission-unit]
             [-o output-file] [-p scamper-port] [-t log-file]
             [-w window]

sc_tbitpmtud [-d dump-id] [-A ip2as-file] [-m maximum-transmission-unit]
             [file ...]

two whole modes, she contains multitudes 💅

---

🦋 DESCRIPTION 🦋

so here's the tea: sc_tbitpmtud is a utility that lets you connect to a scamper(1) instance that's already running, and then use that instance to test end systems for their ability to do Path MTU Discovery. the output gets written to a file in warts format. periodt.

the way it works: sc_tbitpmtud first tests a given system for responsiveness to ICMP echo packets, and then tests that same system's TCP stack response to ICMP packet too big messages. two steps, no shortcuts, iconic behaviour.

the options are as follows:

• -? — prints a list of command line options plus a synopsis of each one. a lil menu, if you will 🎀
• -a address-file — names the input file, which is just a sequence of systems to test, one system per line.
• -A ip2as-file — names a file full of prefix-to-AS mappings, one prefix per line.
• -c completed-file — names a file where the IP addresses that have already been tested get recorded. a lil receipt of your progress 📝
• -d dump-id — the dump ID to use when analyzing the collected data. rn the valid ID values are 1 (mssresults) and 2 (asnresults), which report PMTUD behaviour according to the server's MSS or according to the server's origin ASN.
• -l limit-per-file — how many tbit objects to record per warts file before opening a new file and putting new objects in it. the file is simply full, bestie.
• -m maximum transmission unit — the pseudo maximum transmission unit to use. your choices are 0, 256, 576, 1280, 1480. if you pick 0, sc_tbitpmtud will test each website with all the available MTU choices, going in decreasing size. the default MTU value tested is 1280.
• -o output-file — the name of the file to be written. heads up: the output file uses the warts format.
• -p scamper-port — the port on the local host where scamper(1) is accepting control socket connections.
• -r — shuffles the order in which websites are tested. chaos mode, but make it scientific 🎲
• -t log-file — the name of a file to log the progress output from sc_tbitpmtud that gets generated at run time.
• -w window-size — the maximum number of tests to conduct in parallel. lowkey important: the window size value depends on the value of the -F parameter that was passed to the scamper(1) instance.

---

🌈 EXAMPLES 🌈

using this driver requires a scamper(1) instance that's listening on a port for commands, with a configured firewall. the following invocation uses ipfw(8) firewall rules 1 to 100, with a corresponding window size of 100, and an unrestricted packets per second rate, like so:

scamper -P 31337 -F ipfw:1-100 -w 100 -p 0

now, say you want to test a set of web servers specified in a file named webservers.txt, formatted like this:

1,example.com 5063 192.0.2.1 http://www.example.com/
1,example.com 5063 2001:DB8::1 http://www.example.com/
1,example.com 5063 2001:DB8::2 https://www.example.com/

then this command will test all the servers for responsiveness to ICMP packet too big messages and record raw data into webservers_00.warts, webservers_01.warts, etc:

sc_tbitpmtud -a webservers.txt -p 31337 -o webservers

the webservers.txt file is required to be formatted as above. the format is: numeric ID to pass to tbit, a label for the webserver, the size of the object to be fetched, the IP address to contact, and the URL to use. don't freestyle it 💀

to characterize PMTUD behaviour according to the server's advertised MSS value:

sc_tbitpmtud -d mssresults webservers_*.warts

and given files with IPv4 prefixes in prefix2as4.txt and IPv6 prefixes in prefix2as6.txt, formatted like this:

2001:DB8::     48     64496
2001:DB8:1::   48     64497
192.0.2.0      24     64498

this command will characterize PMTUD behaviour according to the origin ASN of the server:

sc_tbitpmtud -d asnresults -A prefix2as4.txt -A prefix2as6.txt
webservers_*.warts

---

👑 SEE ALSO 👑

• scamper(1), sc_wartsdump(1), sc_warts2json(1), warts(5),
• M. Luckie and B. Stasiewicz, Measuring Path MTU Discovery Behaviour, Proc. ACM/SIGCOMM Internet Measurement Conference 2010.
• A. Medina, M. Allman, and S. Floyd, Measuring Interactions between Transport Protocols and Middleboxes, Proc. ACM/SIGCOMM Internet Measurement Conference 2004.

---

💜 AUTHORS 💜

sc_tbitpmtud was written by Matthew Luckie <mjl@luckie.org.nz>. and Ben Stasiewicz contributed an initial implementation of the Path MTU Discovery TBIT test to scamper, building on the work of Medina et al. we love a collab 🫶

---

and that's the whole page, bestie!! this one's from the Debian manual set, dated March 1, 2018 — she's been out here testing packet too big messages since way back, and she still ate. 💅✨ go forth and measure some Path MTU Discovery behaviour, you've got this. 🦋🌸