TIP: Complete network stack without net.* scripts

[VinzC]

Hi all.

It is possible to have a working network stack without resorting to Gentoo net.* scripts at all on simple configuration. Let's agree on what «simple» is:

• only hardware interfaces are needed, i.e. no virtual interfaces;
• IP addresses delivered through DHCP (eventually APIPA)

In such conditions all hardware interfaces can be configured, even the loopback interface, lo.

Basic configuration

Install Roy Marples' dhcpcd with zeroconf support:

Code: Select all

USE=zeroconf emerge -a dhcpcd

It is of course best to add the USE flag to your favourite /etc/portage/package.use file. Now append the following lines to dhcpcd configuration file:

Code: Select all

# In some cases the loopback interface won't be up, this directive fixes it:
allowinterfaces lo * 

# Configure loopback adapter here
interface lo
static ip_address=127.0.0.1/8

Remove all network scripts from all runlevels:

Code: Select all

rc-update del net.lo boot
rc-update del net.eth0 boot

Add dhcpcd to the boot runlevel:

Code: Select all

rc-update add dhcpcd boot

Wireless interfaces

If you installed wpa_supplicant, just add it to the boot runlevel, dhcpcd will detect the interface, whatever it is called and set its IP address automatically. Also note a nice thing Linux does when having wired and wireless interfaces together on the same network is that the one with the lowest metric takes precedence over existing connections.

Suppose for instance you have an ongoing transfer of a very large file over your wireless interface to an existing network mountpoint. Plug the cable and wait for dhcpcd to set the IP address of the ethernet interface and you'll see the network activity switch to the fastest interface. You don't even need to interrupt and restart the transfer. That feature comes handy when you cannot bond interfaces, especially with wireless.

VPN interfaces

Now dhcpcd will attach to any visible network interface and assign an IP address whenever it can as soon as it discovers one (it dynamically detects them). If you have VPN interfaces dhcpcd will also interfere, which is probably not what you want. You can either constraint dhcpcd to a list of interfaces:

Code: Select all

allowinterfaces eth* wlan0

or exclude a list of interfaces you want it to not touch at all:

Code: Select all

denyinterfaces ppp0 en*

See dhcpcd.conf man pages for more info. If no DHCP server can be contacted for a specific interface an IPv4LL will be assigned. I personally prefer dhcpcd to bind to all interfaces it finds but to the ones I exclude. YMMV.

DNS resolution

Your VPN might be configured with the USEPEERDNS parameter, which affects how DNS resolution works. In general it's a good idea to leave it as it is since being connected to the internet *and* to a private network creates a security hole if traffic is also routed outside the VPN. However if you know what you're doing and still want DNS resolution while using your remote network, here's what to do.

Install dnsmasq and openresolv and create a directory to store name service resolvers for dnsmasq, openresolv will update them as soon as VPN interfaces are created using the remote DNS IP addresses. For instance I stored those files in /etc/dnsmasq.d/ .

Code: Select all

# mkdir /etc/dnsmasq.d
# rc-update add dnsmasq boot

Now update resolvconf.conf and dnsmasq configuration.

Code: Select all

# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
dnsmasq_conf=/etc/dnsmasq.d/openresolv.conf
dnsmasq_resolv=/etc/dnsmasq.d/resolv.conf

# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
name_servers=127.0.0.1

Code: Select all

resolv-file=/etc/dnsmasq.d/resolv.conf
conf-file=/etc/dnsmasq.d/openresolv.conf

dnsmasq won't start yet if it doesn't find openresolv files in /etc/dnsmasq.d.

Code: Select all

touch /etc/dnsmasq.d/openresolv.conf
touch /etc/dnsmasq.d/resolv.conf

dfnsmasq configuration file is huge. You can check it for what it does. See also the man pages for more information and examples.

Update, October 2014: The loopback interface is no longer up by default and needs to be somehow. By default dhcpcd doesn't bring the loopback interface up unless instructed to, which is why dhcpcd.conf now includes this line:

Code: Select all

allowinterfaces lo *

[Dr.Willy]

Code: Select all

# Configure loopback adapter here
interface lo
static ip_address=127.0.0.1/8

Are you sure this is required?

[dmpogo]

Does it detect interfaces if they become available later (like ifplugd) or after radios were off and then on again ?

[VinzC]

Code: Select all

# Configure loopback adapter here
interface lo
static ip_address=127.0.0.1/8

Are you sure this is required?

Never too sure. I assumed since Gentoo net scripts do assign an IP address to the loopback adapter then it is needed somehow. I didn't check without this said.

Does it detect interfaces if they become available later (like ifplugd) or after radios were off and then on again ?

Yes, it does.

[steveL]

Vinz: do you have/can you think of, a similar setup for when we're using a static IP, or is net.eth0 always required in order to tell it the IP/mask and gateway?

[VinzC]

Vinz: do you have/can you think of, a similar setup for when we're using a static IP, or is net.eth0 always required in order to tell it the IP/mask and gateway?

You can check dhcpcd man pages and the static keyword for that, just like I did with lo:

Code: Select all

interface eth0
static ip_address=192.168.0.10/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1

I've been surprised how rich dhcpcd and its manpages are as it can virtually do, well, almost anything (just wondered about coffee ).

Code: Select all

static value
             Configures a static value.  If you set ip_address then dhcpcd
             will not attempt to obtain a lease and just use the value for the
             address with an infinite lease time.

             Here is an example which configures a static address, routes and
             dns.
                   interface eth0
                   static ip_address=192.168.0.10/24
                   static routers=192.168.0.1
                   static domain_name_servers=192.168.0.1

             Here is an example for PPP which gives the destination a default
             route.  It uses the special destination keyword to insert the
             destination address into the value.
                   interface ppp0
                   static ip_address=
                   destination routers

If you don't use static [and no DHCP server exists in the network] dhcpcd will fall back on automatic private local addresses like 169.254.x.y (link-local IP or IPv4LL). And from my observations that kind of addressing seems consistent across reboots. The latter needs further checking though.

[Dr.Willy]

Code: Select all

# Configure loopback adapter here
interface lo
static ip_address=127.0.0.1/8

Are you sure this is required?

Never too sure. I assumed since Gentoo net scripts do assign an IP address to the loopback adapter then it is needed somehow. I didn't check without this said.

I was asking, because I was runnig a dhcpcd-only setup for quite a while and basically all I did was remove all gentoo netscripts and start dhcpcd.
I was wondering if I was missing something or this only worked due to my specific setup.

[VinzC]

I was asking, because I was runnig a dhcpcd-only setup for quite a while and basically all I did was remove all gentoo netscripts and start dhcpcd.
I was wondering if I was missing something or this only worked due to my specific setup.

What I am pretty sure of is that even if it's useless its purpose then falls back to being purely documentary so cannot harm at all.

[djdunn]

awesome thanks for this info, im gonna try it out here as soon as this kernel is done compiling

[shad0w_GR]

What about pre/post up/down functions? I don't see whether this way is simpler to openrc.

[VinzC]

What about pre/post up/down functions?

Fact is dhcpcd has hooks — never tried hence can't tell how it works. Not yet. It might be what you're seeking.

I don't see whether this way is simpler to openrc.

Well, no conf.d/net, no init.d/net.*, all interfaces are configured as soon as they appear without doing anything... You're free to stick to OpenRC if it meets your requirements.

[smartass]

Thank you for sharing this howto VinzC

I'm using OpenRC with dhcpcd and ifplugd and noticed that it's almost redundant, because dhcpcd can do what ifplugd does and having several dhcpcd processes started by OpenRC means you get more default gateways and metrics may not be optimal.

However, a major issue for me with such an automagic dhcpcd setup is that I'm not sure how easy it would be to remove an interface from dhcpcd managed pool and configure it temporarily for some debugging, e.g. some static IP or MAC address.

Are you aware of a way to do this with this automagic dhcpcd exclusive setup?
The only way I could think of is making changes to dhcpcd.conf and then sending some signal to the dhcpcd process to re-read the config file.
However, I couldn't find any signal interface in man dhcpcd, but --rebind seems close, but it will temporarily disable ALL interfaces, I was hoping for something that would operate only on a specific interface and wouldn't interrupt others. --release would operate on the specified interface, but it would also stop the process.

[VinzC]

Thank you for sharing this howto VinzC

My pleasure .

I'm using OpenRC with dhcpcd and ifplugd and noticed that it's almost redundant, because dhcpcd can do what ifplugd does and having several dhcpcd processes started by OpenRC means you get more default gateways and metrics may not be optimal.

However, a major issue for me with such an automagic dhcpcd setup is that I'm not sure how easy it would be to remove an interface from dhcpcd managed pool and configure it temporarily for some debugging, e.g. some static IP or MAC address.

Are you aware of a way to do this with this automagic dhcpcd exclusive setup?
The only way I could think of is making changes to dhcpcd.conf and then sending some signal to the dhcpcd process to re-read the config file.
However, I couldn't find any signal interface in man dhcpcd, but --rebind seems close, but it will temporarily disable ALL interfaces, I was hoping for something that would operate only on a specific interface and wouldn't interrupt others. --release would operate on the specified interface, but it would also stop the process.

I'd have thought of using --release too indeed. Have you tried --release <interface> ?

[smartass]

--release can be applied to a specific interface, but according to the manpage it also causes the managing process to exit

-k, --release
This causes an existing dhcpcd process running on the interface
to release its lease, de-configure the interface and then exit.
dhcpcd then waits until this process has exited.

I'm not sure how dhcpcd is designed, but if it spawned a subprocess for each interface then this approach would be viable.
Does --release <interface> kill the main dhcpcd process (which would be managing at least 2 interfaces) on your setup VinzC?

[VinzC]

Does --release <interface> kill the main dhcpcd process (which would be managing at least 2 interfaces) on your setup VinzC?

the documentation needs some adjustments indeed. I tried dhcpcd --release wlan0 on my laptop, which has eth0 and wlan0 setup with the same instance of dhcpcd; --release wlan0 didn't make the daemon process exit, eth0 still had its IP address. So you can safely run dhcpcd --release <interface> without interfering with the other interfaces; as well the dhcpcd daemon will not exit.

[smartass]

oh, that's nice

So if this works, how would I get it back to normal after I don't need the temporarily released interface anymore?

How did you do it? restarted the main dhcpcd process?

I'd like to do it without restarting the whole main process so I wouldn't interrupt any communication going through other interfaces, right now --rebind looks like the best option, but according to manpage

-n, --rebind
Notifies dhcpcd to reload its configuration and rebind its interfaces.
If dhcpcd is not running, then it starts up as normal.

Sounds like it would reconfigure all interfaces, effectively being the same problem like restarting the main process.

[VinzC]

How did you do it?

I ran dhcpcd --rebind and effectively all the interfaces got a new lease, the ones with an existing lease got it renewed.

I'd like to do it without restarting the whole main process so I wouldn't interrupt any communication going through other interfaces,

I understand it could be a problem if you are "unbinding" more than one interface at the same time. Otherwise why would it be a problem?

right now --rebind looks like the best option, but according to manpage

-n, --rebind
Notifies dhcpcd to reload its configuration and rebind its interfaces.
If dhcpcd is not running, then it starts up as normal.

Sounds like it would reconfigure all interfaces, effectively being the same problem like restarting the main process.

Just do the same as I did: try dhcpcd --rebind <interface> then and see if it works .

[smartass]

I tested --rebind with and without an interface argument. Without an interface argument it behaves as in the man page, with one it rebinds only the specified interface. Yay! I'll send Roy Marples a patch for the manpage (I've already put up a ticket).

I understand it could be a problem if you are "unbinding" more than one interface at the same time. Otherwise why would it be a problem?

If all interfaces got rebinded, an ongoing connection with some protocol that easily breaks could break because the connection would be temporarily interrupted.

A few points for your howto:

• you should rather use the default runlevel, that's what most people use. Simply add a statement that any runlevel can be used, but wpa_supplicant and dhcpcd should be in the same runlevel for the dependency resolution to work properly.
• I'd like to see this eventually on the wiki as an extension of my OpenRC roaming howto which is based on net.* scripts right now and your dhcpcd approach could be an alternative approach or possibly the main one, because it's more roaming-like, the original one could be left as an alternative approach for people that need the power of net.* scripts

[smartass]

I've started using this setup to test it, I like how dhcpcd is automagic

However, there is one slight inconvenience coming from the fact that dhcpcd does not report state to OpenRC as with ifplugd (which can report "inactive"):

• When booting, OpenRC waits for dhcpcd to obtain a lease to provide the net virtual. When no network is available, this means I have to wait for the whole timeout before I can proceed booting.
• After dhcpcd is up and running and report as "started", if I loose my network connection, OpenRC will still think that net is available.
• After rfkilling wireless, wpa_supplicant doesn't seem to get back to manage it (I checked that it's not blocked with rfkill command), because that puts the interface down and wpa_supplicant cannot put it up itself (that's what the init script does).

How do you deal with these issues?

[VinzC]

@smartass:

When booting, OpenRC waits for dhcpcd to obtain a lease to provide the net virtual. When no network is available, this means I have to wait for the whole timeout before I can proceed booting.

I'm not too sure of that. At least what you describe doesn't happen on my laptop, which does not run wpa_supplicant by defaut and I often start my lappy without the cable plugged (not counting when I simply forget the cable). This means I often start my computer and there is no network available except the loopback interface. Besides dhcpcd backgrounds immediately to minimize service startup latency.

I never noticed any sort of time out and always saw my laptop boot in the same timely fashion as when OpenRC was managing the network. I'd have believed since the loopback adapter is always present and configured the network is always considered on. But that's just a guess.

After dhcpcd is up and running and report as "started", if I loose my network connection, OpenRC will still think that net is available.

See above. I also never considered it a problem as I always lost connections temporarily. If the computer starts being sluggish then it's the indication there's a network problem somewhere. I never experienced such a situation since I applied this solution though.

After rfkilling wireless, wpa_supplicant doesn't seem to get back to manage it (I checked that it's not blocked with rfkill command), because that puts the interface down and wpa_supplicant cannot put it up itself (that's what the init script does).

I simply never rfkill! I always start/stop wpa_supplicant when I need the wireless network. I always plug a cable whenever possible and only start wpa_supplicant otherwise. So in your case you might run

Code: Select all

/etc/init.d/wpa_supplicant stop

instead of rfkilling. Also I (manually) unload the wireless card module when wireless is stopped. Never had an issue.

you should rather use the default runlevel, that's what most people use. Simply add a statement that any runlevel can be used, but wpa_supplicant and dhcpcd should be in the same runlevel for the dependency resolution to work properly.

Exact. FYI I used the boot runlevel to have the network start ASAP (as long as the cable is plugged beforehand, of course ).

I'd like to see this eventually on the wiki as an extension of my OpenRC roaming howto which is based on net.* scripts right now and your dhcpcd approach could be an alternative approach or possibly the main one, because it's more roaming-like, the original one could be left as an alternative approach for people that need the power of net.* scripts

I might do that .

[Dr.Willy]

When booting, OpenRC waits for dhcpcd to obtain a lease to provide the net virtual. When no network is available, this means I have to wait for the whole timeout before I can proceed booting.

--background

After dhcpcd is up and running and report as "started", if I loose my network connection, OpenRC will still think that net is available.

no idea, sorry

After rfkilling wireless, wpa_supplicant doesn't seem to get back to manage it (I checked that it's not blocked with rfkill command), because that puts the interface down and wpa_supplicant cannot put it up itself (that's what the init script does).

I don't know what rfkill does, but from a look at it's manpage I don't see much difference to wpa_cli.
What do you use rfkill for?

[smartass]

using --background is the obvious solution, but the dhcpcd init script offers little choice to set it in clean way through /etc/conf.d/

when I don't want to use wireless, I press the wifi switch button on my laptop which is hardware rfkill. It's a lot more convenient than stopping a whole init script.

[VinzC]

when I don't want to use wireless, I press the wifi switch button on my laptop which is hardware rfkill. It's a lot more convenient than stopping a whole init script.

Ah, ok, I see now. On my laptop there's no separate control over Wifi and Bluetooth, both are control with the same key/switch; so I chose to assign Bluetooth control to the RF switch and leave wireless control manual.

[Dr.Willy]

using --background is the obvious solution, but the dhcpcd init script offers little choice to set it in clean way through /etc/conf.d/

man dhcpcd.conf

[smartass]

Thanks Dr. Willy, I should RTFM indeed
I did know about dhcpcd.conf, but I wasn't aware it can set so many things.

VinzC, I use rfkill because AFAIK it can save power (may not be true for all cards). I recommend you assign a special key you don't use very often to issue rfkill through your WM or DE.