p2k18 Hackathon Report: Ken Westerback on dhclient and disklabel

Next up is the report from Ken Westerback (krw@):

Trains! (Strike) Planes! (Strike) Automobiles (Whew)

Having been lucky enough to arrive in Paris at about the same time as Theo (deraadt@, not tb@) and Bob I managed to snag a ride to Nantes with them when both the trains and the planes were supposed to be on strike. Incorrectly in the former's case, as espie@ has pointed out in an earlier report.

Checked into hotel, found the hackroom, claimed an empty spot near pirofti@, powered up the laptop, plugged the phone in to charge, loosened up the typing appendages and leaned in to start working on planned port(s) - Ocaml and friends.

At which point robert@ piped up to say that disklabel(8) hated him and insisted his NTFS GPT partition was FAT12. After an hour or so re-familiarizing myself with the relevant disklabel(8), kernel and fdisk(8) code I was able to deduce that it was fdisk(8) that hated him, not disklabel(8). It turns out that FAT12, FAT16S, FAT16B, NTFS, FAT32, FAT32L, FAT16L, a bunch of hidden OS/2 partition types, and Thinkpad Recovery partitions are all assigned the same GUID. As far as MS is concerned they are all "Basic Data". And thus asking fdisk(8) to change the partition type from FAT12 to NTFS has no effect. And the kernel labels them all MSDOS for disklabel(8) spoofing purposes. The fix would be to examine the actual data in the partitions to distinguish between the types but this seemed unnecessary for a cosmetic flaw.

Then it was beer time. Tomorrow the ports work could commence!

Hackroom, pirofti@, loosening, leaning in, … and guenther@ pipes up to say dhclient(8) hates him. Sigh. guenther@ has a laptop dock thingee that contains a cdce(4). And when he booted his laptop without a cable plugged into the cdce(4) port and used wifi … /etc/resolv.conf got configured by cdce(4) despite not having a link! So wrong DNS server(s), etc.

Turns out that cdce(4) is one of those wonder devices that CAN'T TELL YOU IF IT HAS LINK. And so dhclient(8) must assume it DOES have link. And this led to cdce(4) sucking up an unexpired lease from /var/db/dhclient.leases.cdce0 and configuring the interface and /etc/resolv.conf when (naturally) no server provided a new lease to use.

My first attempted fix -- unload responsibility to device driver maintainers by making them fix drivers to always provide link information -- was rejected. So I wrote a diff that made dhclient(8) configure interfaces with leases from dhclient.leases.<if> ONLY when the device reported that it has link. So cdce(4) and friends would only be configured by a lease received over the wire.

I tossed this over to guenther@ for testing but he was engrossed in serious kernel work and couldn't. Aha! I had no cdce(4) and he needed his dock so I could now get to ports work until someone tested the diff! At which point stsp@ helpfully volunteered that he could provide me a cdce(4) USB device. Grrr. So started a few fruitless hours trying to find a working cable/switch port to do a useful test. Apparently all the good cables were in use and nobody wanted to disconnect themselves to help guenther@. Sad.

Beer time. Tomorrow I could do the test and get back to ports!

Hackroom, pirofti@, etc., etc. Fingers poised … and denis@ piped up to say yacc(1) hated him and he saw that I had just made commits to a bunch of parse.y files. Fortunately others jumped into the conversation and I was able to slink away. Then otto@ showed up on icb and I could start pestering him to look at some pending and developing disklabel(8) diffs.

Beer … well you can guess the rest.

In the end lots of dhclient(8) and disklabel(8) work got done, many interesting and informative conversations took place, but no ports work by me. I will have to keep trying by attending more ports hackathons.

Another excellent event in Nantes. Thanks to gilles@, EpiTech, the OpenBSD Foundation and all the other organizers!

Thank you Ken for the report and your work on non-ports!