Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Manage wired and wireless w/ dhcpcd & wpa-supplicant
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 427
Location: Gainesville, FL, USA

PostPosted: Sat Aug 01, 2020 3:45 am    Post subject: Manage wired and wireless w/ dhcpcd & wpa-supplicant Reply with quote

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.
Back to top
View user's profile Send private message
charles17
Advocate
Advocate


Joined: 02 Mar 2008
Posts: 3540

PostPosted: Sat Aug 01, 2020 4:50 am    Post subject: Reply with quote

Did you follow the wiki articles and did you set the -M option?
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 427
Location: Gainesville, FL, USA

PostPosted: Sat Aug 01, 2020 7:23 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
charles17
Advocate
Advocate


Joined: 02 Mar 2008
Posts: 3540

PostPosted: Sat Aug 01, 2020 9:27 am    Post subject: Reply with quote

miket wrote:
...More than that, the page does not address my prime use case: automatic detection of a live ethernet cable ..

That's the job of DHCPCD.

miket wrote:
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.

Works here with DHCPCD very reliably and without any trouble.
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 427
Location: Gainesville, FL, USA

PostPosted: Sun Aug 02, 2020 4:28 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
UberLord
Retired Dev
Retired Dev


Joined: 18 Sep 2003
Posts: 6801
Location: Blighty

PostPosted: Sun Aug 02, 2020 7:56 pm    Post subject: Reply with quote

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

Code:
dhcpcd --rebind


Pretty sure udev or something will allow custom ACPI hooks to the resume event or open lid event. Don't ask me how to do that though, I don't know.

This will force dhcpcd to rebind all it's active leases - there's a fairly short timeout of 5 seconds by default I think.
A well configured network will NAK dhcpcd's renew request forcing a DISOVER and REQUEST to get you back up and running again quickly.

Now, on Linux it's actually perfectly fine to have many default routes.
You'll notice that the default route over the wired interface has a lower metric than the one over the wireless interface - this means it will prefer wired over wireless.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum