SC_UPTIME(1)

💅 sc_uptime(1) — the manual page, but make it iconic ✨

okay so bestie, listen up. this is the sc_uptime(1) manual page and it's genuinely about to be your new hyperfixation. it's a scamper driver that infers reboot windows for systems with IPv6 addresses. slay. let's get into it 🫶

---

✨ NAME ✨

sc_uptime — scamper driver to infer reboot windows for systems with IPv6 addresses. no cap, that's the whole point 💅

---

🌸 SYNOPSIS 🌸

sc_uptime [-o] [-d dbfile] [-E expire] [-I interval] [-l logfile]
          [-O option] [-p port] [-S srcaddr] [-U unix-socket]
          outfile.warts

sc_uptime [-a] [-d dbfile] [-E expire] [-O option] addrfile.txt

sc_uptime [-c] [-d dbfile] [-O option]

sc_uptime [-i] [-d dbfile] [-O option] file ...

sc_uptime [-r] [-d dbfile] [-O option] ip ...

sc_uptime [-x] [-d dbfile] [-O option] do-not-probe.txt

---

🦋 DESCRIPTION 🦋

so the sc_uptime utility literally lets you connect to a running scamper(1) instance and use it to collect data for inferring if and when a system with an IPv6 address rebooted. main character energy fr fr 😭

here's the tea: sc_uptime induces each system to send fragmented ICMP echo replies, with the goal of obtaining an incrementing Identifier (ID) field in the fragmentation header. if the system assigns ID values from a counter, and the counter resets to zero, the system rebooted in the interval between probes. iconic detective work honestly 🔥

ngl, this technique does not work if: - the system does not send ICMP6 fragments - fragments are blocked - the system assigns ID values randomly so keep that in mind bestie, it's giving "results may vary" 💀

sc_uptime implements a scalable algorithm to avoid probing systems that assign ID values at random or are unresponsive. further information about the algorithm is found in the "see also" section. massive brain energy 🧚

the supported options to sc_uptime are as follows:

---

🎀 OPTIONS 🎀

• -a — specifies the name of the input file which consists of a sequence of IPv6 addresses to probe for reboots, one address per line. any new addresses are added to the sqlite3 database for subsequent processing. any addresses in the sqlite3 database but not in the addressfile continue to be probed. lowkey convenient ✨
• -c — specifies that a sqlite3 database file is to be created. the mode of database is specified with -O. yes bestie, you gotta pair it with -O 💖
• -d dbfile — specifies the name of the output sqlite3 database file to use. that's your dbfile, your vibes container 🗂️
• -E expire — specifies the length of time, in days, that an address may remain in the probe state database after last being seen in traceroute, and not responding with incrementing IPID values. it's giving expiry date but for probe states ⏳
• -i — specifies that the IPID samples in the supplied warts(5) files should be imported into the sqlite3 database. yup, import szn 📥
• -I interval — specifies the desired probe interval, in seconds, for each address. set your rhythm, bestie ⏱️
• -l logfile — specifies the name of a file to log progress output from sc_uptime generated at run time. for the girlies who love receipts 📝
• -o — specifies the name of the output file to be written. the output file will use the warts(5) format. fancy ✨
• -O options — allows the behavior of sc_uptime to be further tailored. the current choices for this option are:
  • init-state: initialise a brand new sqlite3 database for data collection. use this option with -c. fresh start energy 🌱
  • init-data: initialise a brand new sqlite3 database for data analysis. use this option with -c. also fresh, also with -c 💫
  • safe-db: when importing into the data database, use safe operations. by default, sc_uptime enables optimizations that will speed up bulk data importing, at the expense of possible database corruption in the event power is lost during the import. so like, safe-db is the responsible choice, but the default is the speedy-and-risk-it-for-the-biscuit choice 😬
  • vacuum-db: perform a database vacuum before doing any operations. tidy up before you start, periodt 🧹
• -p port — specifies the port on the local host where scamper(1) is accepting control socket connections. port is giving "where's the party at" 🎉
• -r — specifies that sc_uptime should use the IPID samples in the sqlite3 database to infer reboots. the actual inference step, the moment we've all been waiting for 🔍
• -S srcaddr — specifies the unicast IPv6 source address to use in probes. this option is recommended when the prober has multiple or changing IPv6 addresses, as some probed systems maintain an IPID counter related to the source IPv6 address of the prober. if the source address of probes changes, the returned IPID sequence could have a discontinuity unrelated to a reboot of the probed system. so like, keep your source address stable or you'll get fake reboot vibes, no cap 💅
• -U unix-socket — specifies the name of a unix domain socket where scamper(1) is accepting control socket connections. unix socket bestie, the local legend 🔌
• -x — specifies that the do-not-probe list has been updated and the state database should be cleared of matching addresses. the do-not-probe file is a text file with one prefix per line. individual addresses may be specified by including the address without a suffix. bye felicia to the addresses on the naughty list 👋

---

💖 EXAMPLES 💖

okay so first things first. given a set of IPv6 addresses contained in a file named addrs.txt and a scamper process listening on port 31337 configured to probe at 30 packets per second, started as follows:

scamper -P 31337 -p 30

the following command will create a sqlite3 database named state.sqlite to record probe state within, probe the addresses contained in addrs.txt once to collect raw data that can be used to infer reboot windows, and store the raw data in out1.warts:

sc_uptime -p 31337 -O create-db -d state.sqlite -a addrs.txt -o
out1.warts

to infer reboot windows, sc_uptime must be run in rounds. the next time sc_uptime is run, use:

sc_uptime -p 31337 -d state.sqlite -o out2.warts

import the IPID samples from out1.warts and out2.warts into a separate probe database:

sc_uptime -i -O create-db -d data.sqlite out1.warts out2.warts

infer reboots across all imported data:

sc_uptime -r -d data.sqlite

to infer reboots just for IPv6 address 2001:DB8::1, use:

sc_uptime -r -d data.sqlite 2001:DB8::1

look at you go bestie, you're basically a network detective now 🕵️‍♀️✨

---

🌈 HINTS 🌈

• store the state.sqlite file on a memory file system to improve speed and reduce disk wear. your SSD will thank you 💾
• in between invocations of sc_uptime, copy the state.sqlite file to disk. don't lose your progress, bestie 😭
• you can store probe data in the same database used to maintain state, but you should use a separate database. like, you can but... don't 🙈
• to obtain better performance, import the data into a time-series database. future you will be obsessed ⭐

---

💀 NOTES 💀

sc_uptime will only probe addresses in 2000::/3. that's the rule, bestie. no exceptions, periodt 💅

---

👑 SEE ALSO 👑

scamper(1), sc_ally(1), sc_ipiddump(1), sc_speedtrap(1), sc_wartsdump(1), sc_warts2text(1), sc_warts2json(1), sqlite(1), warts(5),

M. Luckie and R. Beverly, The Impact of Router Outages on the AS-level Internet, Proc. ACM/SIGCOMM Conference 2017.

R. Beverly, M. Luckie, L. Mosley, and k claffy, Measuring and Characterizing IPv6 Router Availability, Proc. PAM 2015.

iykyk, these are the receipts 📚🔥

---

🫶 AUTHORS 🫶

sc_uptime was written by Matthew Luckie and Robert Beverly. absolute icons, honestly 👑👑

---

created with 💖 by the Debian fam • July 2, 2017 • you're welcome bestie, go infer some reboots ✨💅🦋