Manage wired and wireless w/ dhcpcd & wpa-supplicant

[miket]

I have a laptop with OpenRC, dchpcd, dhcpcd-ui, and wpa-supplicant. I prefer to use wired ethernet but will use a wireless connection when I have to. Switching among multiple 802.11 access points is smooth enough; switching from wired to wireless works most of the time; but going from wireless to wired almost always requires hand-tweaking the default route and /etc/resolv.conf. I know it shouldn't be like this, but I'm not clear on how to fix it.

Roy Marples had a solution in another forum post, a solution that involves arping a known private IP address. Yes, that technique allows for fast switching of interfaces, but it's not so hot if you expect to plug into multiple wired networks.

I'd like something that is sensitive to activity on the ethernet port, even if it requires a udev rule. Somehow I imagine it's within the capabilities of one of these pieces of software. The documentation for both of wpa-supplicant and dhcpcd speaks about multiple interfaces, but I don't know where to apply the needed changes. I get the sense it would be in dhcpcd alone, but I'm not sure.

[charles17]

Did you follow the wiki articles and did you set the -M option?

[miket]

Alas, I did try to make sense of the articles and indeed the -M switch was already set in /etc/conf.d/wpa_supplicant.

The daemon already knows the path /etc/wpa_supplicant/wpa_supplicant.conf, so there's no need to set that in /etc/conf.d/ as the wiki page shows (otherwise it would not be able to find information about networks it knows about). The example the wiki page gives for wired networking has wpa_supplicant negotiate with an 802.1X authenticator. The wiki page does say that it can handle starting and stopping interfaces if it is running in the default runlevel (as it is in my system), but is silent on the matter of plain ethernet networks without fancy authentication.

More than that, the page does not address my prime use case: automatic detection of a live ethernet cable in order to switch traffic to the ethernet interface. I suspect--but don't know for sure--that in order for the kernel to detect a change in the ethernet state, the interface has to be up. That wouldn't work if wpa_supplicant takes down the eth0 interface in order to start communicating over wlan0.

As I understand it, dhcpcd is the network manager, so it is the one with the responsibility. Before I switched to dhcpcd in this role, I used wicd. For all its flakiness, one thing that wicd did well was detect when eth0 had a cable plugged in.

[charles17]

[miket]

Sorry Charlie (to use the tagline for Starkist Tuna), but that still doesn't solve my problem. The documentation was not helpful for my problem and led me a bit astray (see below). More than that, no one responded to my two related questions in the Desktop forum. So I took a deep dive into the sources for dhcpcd and dhcpcd-ui, the documentation for wpa_supplicant and Linux networking, and some RFC's to get a picture of how these are supposed to work and what may be going wrong. Let's just say that network management is interesting. I know that I don't have all the details right, but I am more right than wrong.

Things start in the kernel, which handles events from all kinds of sources. Userland processes communicate w/ the kernel over sockets opened on a special address family, packet socket. Daemons such as wpa_supplicant and dhcpcd listen over this firehose of events to obtain whatever is useful to them.

So far as I can see, wpa_supplicant has three main functions: monitor signal strength and encryption type of wireless access points, set up and break down connections to wireless access points according to user interaction or configured SSID's, and authenticate the guest on networks (wired or wireless) that require authentication.

Next in the chain is dhcpcd. It does not communicate directly with wpa_supplicant but only indirectly via packet socket. It looks for an interface to come up before deciding how to configure it (viz. negotiate a dynamic address or use a static one). It sets the interface with correct parameters (IP addresses, gateway, etc), alters the routing table, and updates /etc/resolv.conf. Preference for wired interfaces is automatic.

Last in the chain for network management is dhcpcd-ui. It does not listen to packet socket but instead polls wpa_supplicant in order to discover newly available SSID's, signal strengths, and associated networks. It has some unfortunate deficiencies in relation to wired networks--but that's taken up in the other forum thread.


So fine. I did already have things configured with dhcpcd as a network manager. Yes, things ought to switch smoothly when I plug in the ethernet cable, but how to resolve my problem? Very distracting--and completely unnecessary, as it turns out--was the suggestion to pay attention to the wiki pages. The line in the wpa_supplicant article that I cited in an earlier post was misleading. Yes wpa_supplicant brings up and takes down interfaces, but that's only for changes in runlevel or the user flipping the enable-wireless-networking switch. There was no need for me to change the wpa_supplicant configuration--at least in ways suggested in the wiki pages for dealing with wired interfaces.

It turns out that the problem occurs only when suspending the laptop between changes in environment. Here is what I was doing.
1. Suspend the laptop with the ethernet cable plugged in
2. Take it somewhere where wireless is available but ethernet is not
3. Open the lid. Wpa_supplicant associates with the access point
4. Supend the laptop before returning home
5. Plug in the power and ethernet cables
6. Open the lid.

It's at both points 3 and 6 where I find that I have extraneous entries in /etc/resolv.conf and two default routes.

Hmph. It's at this point I realize I'm dealing with a race condition. Those are bad enough to figure out in a single bit of code, but I sure don't want to try to unravel the interaction between kernel, wpa_supplicant, and dhcpcd!

The best I can do is a mitigation. When modify my procedure, things work out correctly:
1. Unplug the ethernet cable, *then* suspend the laptop
2. Take it somewhere where wireless is available but ethernet is not
3. Open the lid. Wpa_supplicant associates with the access point and the routing table is sane
4. Supend the laptop before returning home
5. Plug in the power cable, open the lid, and enter the password to unlock the screen
6. Plug in the ethernet cable. Dhcpcd discovers it and clears out extraneous routing and resolution entries

The key is to have the ethernet cable unplugged when suspending or unsuspending.

[UberLord]

If the system is not behaving correctly (ie enforce carrier down at wakeup and then check if we have one or not and emit a carrier up) you can force dhcpcd to renegotiate quickly by issuing