dhcpcd-discuss

Hi Justin

On 18/09/2020 22:05, Justin Humm wrote:
> I have trouble configuring my interface with Dhcpcd when using Linux
> network namespaces (netns). My use case is to eventually configure a
> Wireguard VPN using a namespace `physical` for enp0s25 and another
> namespace `1` for applications communicating over the VPN. That's also
> the recommended way to set up by the Wireguard project [0].
>
> # Reproducing the error
>
> I'm using dhcpcd from latest master (01e57be54c56f6fbe0566e3aff438588030581f9).
>
>    # uname -a
>    Linux maschine 5.4.65 #1-NixOS SMP Sat Sep 12 12:18:56 UTC 2020 x86_64 GNU/Linux
>
> Also no dhcpcd process is running.
>
>    # dhcpcd --exit
>
> Test that dhcpcd without any namespaces runs fine for both setting the
> interface via config file as well as providing the interface as an
> argument.
>
>    # cat dhcpcd.config
>    allowinterfaces enp0s25
>
>    # dhcpcd --oneshot --debug --config dhcpcd.config
>    ... runs fine
>
>    # dhcpcd --oneshot --debug enp0s25
>    ... runs fine
>
> Then I add a namespace physical and put my ethernet interface in it.
>
>    # ip netns add physical
>
>    # ip link set enp0s25 netns physical
>
> Now I run dhcpcd inside the physical network namespace. Weird thing is
> that configuring the interface by providing it via the command line
> works fine, while…
>
>    # ip netns exec physical dhcpcd --oneshot --debug enp0s25
>    ... runs fine
>
> …using the config file fails with "no valid interfaces found".
>
>    # ip netns exec physical dhcpcd --oneshot --debug --config dhcpcd.config
>    no such user dhcpcd
>    dhcpcd-9.2.0 starting
>    udev: starting
>    dev: loaded udev
>    DUID Redacted
>    no valid interfaces found
>    exiting due to oneshot
>    no interfaces have a carrier
>    exiting due to oneshot
>    dev: unloaded udev
>    dhcpcd exited
>
>
> # Expected behaviour
>
> I'd expect it to configure fine with an interface provided via
> allowinterfaces in the config file. Also it would be nice to receive some
> more logging for what interfaces where detected and why they were found
> to be not valid.
>
>
> Any idea what is the problem here?

Wow, this was an interesting one :)
So udev has the ability to rename interfaces.
One facet of this is that IF udev is running we need to ignore the kernel 
announcing interfaces AND listen to udev instead. Also on startup, we need to 
query udev to see if the interface name is stable and can be used.

Running in a network namespace, udev (correctly) claims the interface does not 
exist. This is because it shares the same filesystem as root so it can contact 
udev but the interface is not in the root namespace.

So the solution is to disable udev when dhcpcd is run in a network namespace.

Specifying an interface on the commandline bypasses udev.

Fixed here:
https://roy.marples.name/cgit/dhcpcd.git/commit/?id=802d6bf1aa92224cdfd40d95a2fd5d1b4477abb1

Let me know if it works for you!

Roy