Years ago, I had to deal with some
aggravation around IPv6. My connection to my ISP is such that I'm
using PPPoE which means I have to use an MTU of 1492 instead
of the ubiquitous 1500 that everyone else is using:
# ifconfig tun1 tun1: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1492
I'm using Wireguard in various places to link
multiple networks. Wireguard packets have 80 bytes of overhead, so the
virtual interfaces it creates have an MTU of 1420 by default.
You can probably guess where this is going.
On a connection such as mine, a packet of size 1420 plus the 80 bytes of
overhead is 1500. This means we'll run into all of the same problems that
occurred with IPv6 back in 2017, with all of the same symptoms.
The solution? Set an MTU of 1410 on the Wireguard interfaces.
On FreeBSD:
# ifconfig wg0 mtu 1410
On Linux, you can either use an MTU=1410 directive in the Wireguard
configuration file, or:
# ip link set mtu 1410 up dev wg0
Like any good obsessive, I keep an inventory of computer parts, tools, and so on. The inventory keeps track of serial numbers so that I can answer questions like "Which machine did that PSU end up being installed into?" and "When those addicts from that failing machine learning company broke in, which GPUs did they take?".
I recently bought a Dremel 8260 to do some guitar body routing tasks, and other miscellaneous bits of cutting and drilling. I've got no complaints with it, although I ran into a pretty immediate problem when trying to check it into the inventory.
Dremel are a division of Bosch, and it seems like Bosch have gotten into the habit of not putting serial numbers onto tools, or at least not doing it in any obvious way.
I have a Bosch GSB 18V-45 here and there's no serial number printed anywhere on the case. The same goes for the Dremel 8260.
There is, however, a QR code on both. Scanning the QR code on the drill yields the following redacted text:
240516_80103601JK3300_xxxxxxxxxxxxx
^^^^^^^^^^^^^
The underscore characters are actually the U+241D GROUP SEPARATOR character,
but that wouldn't be printable in most browsers so I've replaced it with an
underscore here. The xxxxxxxxxxxxx string I've redacted because I believe it
actually is a serial number. The 240516 string looks like a date, but it
doesn't match up with anything date related on the tool itself (the tool is
from 2023). It presumably has some internal meaning to Bosch. If you dump the
string 80103601JK3300 into any search engine, the first result that comes
up is service information for the drill, so that number is presumably a model
number.
The Dremel has two QR codes. One QR code simply restates the model number, but the other QR code hidden inside the battery compartment yields:
240511_8010F013826077_xxxxxxxxxxxxx
^^^^^^^^^^^^^
Again, dumping 8010F013826077 into a search engine yields service information
for the Dremel 8260, so it is probably a model number. The 240511 string means
something to someone somewhere at Bosch. The xxxxxxxxxxxxx string might
be a serial number.
Neither of the xxxxxxxxxxxxx values are actually printed anywhere on the
tools, and there's no documentation whatsoever online that I could find about
how to locate serial numbers on Bosch tools. I'm not up for buying another
instance of either tool just so that I can compare the xxxxxxxxxxxxx values.
Searching for those values online yields nothing, which in itself is evidence
that they might just be unique-and-otherwise-meaningless serial numbers.
I emailed Bosch to ask them where I can find the serial numbers on my tools. I got a supremely confusing message back saying that Bosch's legal team might be inspecting the message (?), followed a few days later by a message from a support team suggesting that I register the tool online. The message seemed to indicate that they hadn't read my initial message at all, or at least hadn't understood it. I did register the tools online and, predictably, this didn't result in the serial numbers being magically revealed (there's no way it could have; I wasn't even required to submit any kind of proof of purchase or scan anything on the tools, so presumably registration is just a way to get a bit of data out of me for marketing purposes).
I'm not sure what's so difficult about putting an unambiguous serial number somewhere visible on the case. Computer parts manufacturers seem to manage to do it just fine. Who benefits from keeping things obscure like this?
I'm planning to move hosting from Vultr to Hetzner. I can't fault Vultr, I've been with them since 2017. The functionality Vultr provide, their transparent pricing, and their technical support have all been great. I've often filed support tickets and had them resolved within a couple of minutes of posting.
However, Hetzner have better pricing (they'll give me roughly four times the compute resources for the same price as Vultr), have technical support that's reportedly equal to Vultr, and are based in a jurisdiction with stronger data protection laws. Additionally, they build and operate their own datacenters as opposed to renting space in someone else's, which really appeals to me as someone who tries to run as much of his own infrastructure as possible.
I'll have to add a Hetzner DNS plugin to certusine in order to issue certificates on the new infrastructure. That seems easy enough as the API looks almost identical to the one Vultr provide. I suppose there aren't all that many ways to manage DNS records.
I did end up buying 6 × 8TB drives.
Specifically:
- 2 × Western Digital Pro Red 8TB
- 2 × Toshiba N300 M/N 8TB
- 2 × Seagate IronWolf NAS 8TB
About a week ago, one of the Toshiba drives started producing I/O errors:
pool: storage state: ONLINE status: One or more devices are faulted in response to persistent errors. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the faulted device, or use 'zpool clear' to mark the device repaired. scan: scrub repaired 0B in 00:00:00 with 0 errors on Sat Nov 23 19:31:35 2024 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 sdf FAULTED 38 37 0 too many errors sdg ONLINE 0 0 0 sda ONLINE 0 0 0 sdc ONLINE 0 0 0 sdb ONLINE 0 0 0 sdd ONLINE 0 0 0
Upon attempting to scrub the array, the drive was immediately rejected by the
system and no longer appeared in /dev. Putting my ear to the rack, I could
hear pretty nasty mechanical scraping and clicking noises.
So... A replacement is on the way. No data loss, obviously, as it's a RAIDZ2 array.
It's that time of year again.
Fingerprint | Comment --------------------------------------------------------------------------- EEB8 AB46 DD49 21F9 2D65 2951 AF65 0323 17B1 1325 | 2025 personal 12BC 7CF4 BB72 BD17 F7F5 01EB 3A1B 34F8 9D7A D0FC | 2025 github-ci-maven-rsa-key DCC0 6058 9E82 6BA3 ED0D DE0A 50C2 29F9 70F3 B691 | 2025 maven-rsa-key FD46 A5BE 7346 1BB3 281E 4126 8352 B398 51FD A294 | 2025 android APK signing key
Keys are published to the keyservers as usual.