The other day my DSL connection went down (as it has before). However, this time around I have a smartphone so I was able to put into action my plan for a backup Internet connection, namely tethering my home machine through my phone. The basic mechanics were as straightforward as the various commentators said they'd be; I plugged my phone into a USB cable to my computer, turned on the phone's personal hotspot feature, and my machine magically had a new Ethernet device I could talk to (courtesy of the ipheth driver).

(The one wrinkle is that I had to turn wireless off on the phone, because of course it was connecting to my home wireless network and thus trying to send its traffic out through my machine and the non-working DSL connection.)

If I was using a conventional GNOME or KDE or whatever desktop environment, this would have been basically it. I'd have told NetworkManager to use the new network, it would have fired up DHCP and so on, and everything would have just worked. However, I have an extremely custom window manager setup and don't use NetworkManager, so I needed to run or at least set up a DHCP client for this by hand. What I wanted was a simple and minimal client setup; it should attempt DHCP on only a single interface, do very little with networking, and only do any of this when I explicitly wanted DHCP to be active on that interface.

Fedora 24 packages and seems to install by default dhclient, the ISC DHCP client. I initially misread the manpage and thought I needed another DHCP client but it turns out that using dhclient will work, although it's a little bit awkward and by default dhclient wants to manage your /etc/resolv.conf too.

(That dhclient is good enough is convenient, because Fedora doesn't seem to package any other relatively standalone DHCP client. Or at least not any of the ones that people suggested on Twitter.)

The basic process of using dhclient for this is that you run 'dhclient eth0' (as root), which will background itself once it's obtained a lease from the iPhone. Once it has the lease it will also set up a working default route and will normally try to set up a resolv.conf that points to the iPhone. To stop a running dhclient, you run 'dhclient -r'; this will release the lease and remove the default route and so on.

(If you run plain 'dhclient' by accident, without a network device, it may look at random other interfaces and do DHCP on them and the whole thing probably won't work too well.)

This handled most of the situation but left me with the issue of what to do about /etc/resolv.conf. At first I mangled things so that I kept my normal one, which points to a local Unbound instance, and while that mostly worked it was less than ideal. The tipping point was realizing that my local Unbound now couldn't resolve things in our subdomain properly because it was pointing to internal nameservers that were now inaccessible to me, but I think it was also flooding the tethering and having a number of its queries dropped (certainly I had DNS resolution issues). So I switched over to using the DHCP-provided DNS server information while I had tethering active. This required some blunt force hackery.

I have two goals for the /etc/resolv.confs that result here. First, the DHCP-based resolv.conf needs to have the correct search path and options. I do this by having an /etc/dhcp/dhclient-enter-hooks file that sets some environment variables:

SEARCH="cs.toronto.edu toronto.edu"
RES_OPTIONS="ndots:1"

(These variables are not documented; I got them by reading /usr/sbin/dhclient-script.)

Second, I want my regular /etc/resolv.conf to be restored when DHCP stops. To do this I saved a copy in /etc/resolv.conf-dsl and created an /etc/dhcp/dhclient-eth0-down-hooks script that does:

rsync -a /etc/resolv.conf-dsl /etc/resolv.conf

I don't think there's any standard behavior in dhclient et al to do this, so I believe if you shut down DHCP you normally wind up with whatever resolv.conf was last written by dhclient-script.

There are probably better ways to do all of this, but I was working in a hurry, changing my mind about what I wanted to do, and not focusing too much on trying to figure out the exactly correct way to do everything. If it worked that was good enough for me at the time.

(I actually started out using dhclient-enter-hooks to (re)define my own make_resolv_conf shell function, which wrote the DHCP-determined resolv.conf information to a different location so I could see what DNS setup information dhclient was getting back. When I decided to use that DHCP DNS information for real I took out the function definition and replaced it with just the variables, which I'd found since I was reading the stock make_resolv_conf function to determine what information it got passed and how.)

PS: Note that the Fedora 24 dhclient-script manpage is incomplete, as may be the manpage that your distribution ships. The Fedora 24 version loads hooks from /etc/dhcp/dhclient-enter-hooks.d, for example, and also appears to load settings from an /etc/sysconfig/network-scripts/ifcfg-<interface> file if you have one for the interface. But all of this is undocumented and I haven't tried out most of it, so caveat emptor.