# 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:

```
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:

```
# 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:

```
rc-update del net.lo boot

rc-update del net.eth0 boot
```

Add dhcpcd to the boot runlevel:

```
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:

```
allowinterfaces eth* wlan0
```

or exclude a list of interfaces you want it to not touch at 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/ .

```
# mkdir /etc/dnsmasq.d

# rc-update add dnsmasq boot
```

Now update resolvconf.conf and dnsmasq configuration.

```
# 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
```

```
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.

```
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: 

```
allowinterfaces lo *
```

----------

## Dr.Willy

 *VinzC wrote:*   

> 
> 
> ```
> # Configure loopback adapter here
> 
> ...

 

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

```
# Configure loopback adapter here

interface lo

static ip_address=127.0.0.1/8
```

 *Dr.Willy wrote:*   

> 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.

 *dmpogo wrote:*   

> 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

 *steveL wrote:*   

> 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:

```
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  :Wink:  ).

```
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

 *VinzC wrote:*   

> 
> 
> ```
> # Configure loopback adapter here
> 
> ...

 

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

 *Dr.Willy wrote:*   

> 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

 *shad0w_GR wrote:*   

> 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.

 *shad0w_GR wrote:*   

> 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  :Smile: 

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

 *smartass wrote:*   

> Thank you for sharing this howto VinzC 

 

My pleasure  :Smile:  .

 *smartass wrote:*   

> 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? 
> ...

 

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

 *man dhcpcd wrote:*   

> 
> 
>     -k, --release
> 
>              This causes an existing dhcpcd process running on the interface
> ...

 

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

 *smartass wrote:*   

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

 

 :Very Happy:  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  :Smile: 

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

 *man dhcpcd wrote:*   

> 
> 
>      -n, --rebind
> 
>              Notifies dhcpcd to reload its configuration and rebind its interfaces.
> ...

 

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

----------

## VinzC

 *smartass wrote:*   

> 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.

 *smartass wrote:*   

> 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?

 *smartass wrote:*   

> right now --rebind looks like the best option, but according to manpage
> 
>  *man dhcpcd wrote:*   
> 
>      -n, --rebind
> ...

 

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

----------

## 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!  :Smile:  I'll send Roy Marples a patch for the manpage (I've already put up a ticket).

 *VinzC wrote:*   

> 
> 
> 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  :Smile: 

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:

 *Quote:*   

> 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.

 *Quote:*   

> 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.

 *Quote:*   

> 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 

```
/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.

 *Quote:*   

> 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  :Very Happy: ).

 *Quote:*   

> 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  :Smile:  .

----------

## Dr.Willy

 *smartass wrote:*   

> 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

 *smartass wrote:*   

> 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

 *smartass wrote:*   

> 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

 *smartass wrote:*   

> 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

 *smartass wrote:*   

> 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  :Wink: 

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.

----------

## VinzC

 *smartass wrote:*   

> 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.

 

Not required. IIRC unloading the kernel module (iwlwifi) is enough to stop the wireless adapter (at least on my machine). As far as power is concerned the video adapter (Radeon) consumes far more than the wifi card, alas, which shows a negligible consumption in comparison. [OT: That's why I'm looking forward to 3.11 and DPM for ATI cards. But that's another story.]

----------

## UberLord

I would just like to say thanks to VincZ for documenting and promoting what I originally set out to do with the OpenRC network (not the net.*) script and dhcpcd.

Basically, configure conf.d/network to brink up the link (bridging, bonding, authentication, etc) and let dhcpcd handle everything else.

Of note re wpa_supplicant, dhcpcd-6 will start (and stop) wpa_supplicant if /etc/wpa_supplicant.conf exists by itself.

This is handy because I can now plug and unplug a USB wifi card and It Just Works  :Smile: 

No need for udev, ifplugd, NM or anything else.

----------

## smartass

 *UberLord wrote:*   

> 
> 
> Of note re wpa_supplicant, dhcpcd-6 will start (and stop) wpa_supplicant if /etc/wpa_supplicant.conf exists by itself.
> 
> This is handy because I can now plug and unplug a USB wifi card and It Just Works 
> ...

  I appreciate that you've added so many features, but isn't it a bit too far against the unixy way of having one tool do its job well and do only that job?

OTOH, it's incredible that you've managed to this on your own in one tool and the people at RH have been failing to make it so simple and automagic for years  :Very Happy: 

But seriously, isn't it a bit close to reinventing the wheel?

----------

## UberLord

 *smartass wrote:*   

>  *UberLord wrote:*   
> 
> Of note re wpa_supplicant, dhcpcd-6 will start (and stop) wpa_supplicant if /etc/wpa_supplicant.conf exists by itself.
> 
> This is handy because I can now plug and unplug a USB wifi card and It Just Works 
> ...

 

Not at all, when you view that the job of dhcpcd is just to configure network interfaces - it's not just a DHCP client.

And it does configure network interfaces very very well  :Smile: 

OK, interacting so directly with wpa_supplicant is a little out of scope as dhcpcd doesn't really want to manage link configuration BUT it's a great example of how the hook scripts work.

The main reason why I included it is for the benefit of the BSD systems I also use where the user is entirely expected to script hotplugging, unlike say in Gentoo where this is achieved via udev and OpenRC automatically.

 *Quote:*   

> 
> 
> OTOH, it's incredible that you've managed to this on your own in one tool and the people at RH have been failing to make it so simple and automagic for years 
> 
> But seriously, isn't it a bit close to reinventing the wheel?

 

Thanks  :Smile: 

It's not re-inventing the wheel at all. It's about making the wheel better with less maintenance.

Think about how many different parts other systems have, now think about many different parts dhcpcd has.

----------

## VinzC

 *UberLord wrote:*   

> I would just like to say thanks to VincZ for documenting and promoting what I originally set out to do with the OpenRC network (not the net.*) script and dhcpcd. [...]

 

It's my pleasure, Roy, totally.

Even after hacking the network stack and creating my own set of tools I still felt like I had underused dhcpcd all those years. So I dug a little and decided to share my findings. And I have to admit it is a remarkable tool of simplicity.

----------

## xaviermiller

Hello,

I tried the tip, and I would like to migrate preup() and postup() hooks I have in /etc/conf.d/net, especially the SSID variable. But moving preup() and postup() from net to network don't help.

Any idea?  :Wink: 

----------

## smartass

XavierMiller, you could use the hooks framework that dhcpcd offers. See the manual page of 

```
dhcpcd-run-hooks
```

 according to 

```
dhcpcd --variables
```

the ssid variable can be set, so you could add a case construct for that.

----------

## xaviermiller

Thank you, I will take a look tonight  :Wink: 

----------

## Dr.Willy

wireless specific actions can also be triggered via "wpa_cli -a <script>"

----------

## xaviermiller

Hello,

I have an other issue : wpa_supplicant is not run on hotplugged wlan interfaces (usb sticks). If I restart the service, the USB stick is activated.

----------

## VinzC

 *XavierMiller wrote:*   

> I have an other issue : wpa_supplicant is not run on hotplugged wlan interfaces (usb sticks). If I restart the service, the USB stick is activated.

 

Have you installed >=dhcpcd-6.0 ?

----------

## xaviermiller

Yup, I'm running ~arch

```
[ebuild   R    ] net-misc/dhcpcd-6.0.5-r1  USE="-ipv6" 0 kB
```

PS: if I pollute that thread, I could open a new one.

----------

## xaviermiller

I will take a look at this wpa_supplicant hook : http://fossies.org/linux/misc/dhcpcd-6.0.5.tar.gz:a/dhcpcd-6.0.5/dhcpcd-hooks/10-wpa_supplicant

EDIT: found! The hook looks /etc/wpa_supplicant.conf which is not correct in Gentoo. If I create a symlink, wpa_supplicant is managed by dhcpcd

I will file a bug  :Wink: 

----------

## VinzC

 *XavierMiller wrote:*   

> I will take a look at this wpa_supplicant hook : http://fossies.org/linux/misc/dhcpcd-6.0.5.tar.gz:a/dhcpcd-6.0.5/dhcpcd-hooks/10-wpa_supplicant
> 
> EDIT: found! The hook looks /etc/wpa_supplicant.conf which is not correct in Gentoo. If I create a symlink, wpa_supplicant is managed by dhcpcd
> 
> I will file a bug 

 

IMHO the bug is not needed as it looks like a configuration parameter. Try setting wpa_supplicant_conf in dhcpcd.conf to the real path and see how it works.

----------

## xaviermiller

it also works  :Smile: 

For the moment, I write my hook to set-up some hostpot scripts and other stuff, and it seems to work.

EDIT: it works !

----------

## Naib

one question. Why?

----------

## xaviermiller

Because I don't want to need nice GUIs, which are unnecessary to configure 2-3 networks. And so, I avoid unnecessary bullshit that change every 2 years (HAL, Systemd, *kit). 

And I need to configure 2 things depending on the discovered network 

- set DISTCC features at home, when the distcc server is up and running

- execute a logon script on hotspot used at work

Because KISS.

----------

## VinzC

 *Naib wrote:*   

> one question. Why?

 

 *XavierMiller wrote:*   

> Because I don't want to need nice GUIs, which are unnecessary to configure 2-3 networks. And so, I avoid unnecessary bullshit that change every 2 years (HAL, Systemd, *kit).
> 
> [...]
> 
> Because KISS.

 

Ditto.

----------

## Incomplet

dhcpcd is perhaps the most awesome piece of software that I've ever come across. It's awesome even if you don't configure it, and more awesome when you do. It's also the most reliable network manager that I have ever used, free or otherwise. The network manager on OSX would randomly stop working and if the network went screwy there was no chance of bringing it back without a restart (or two). On windows the manager does screwy things sometimes, and you never know what kind of garbage MS has in the pipe at any time. dhcpcd, on the other hand, has always "just worked" for me, no matter what (although the rest of my system is another story..). The wind will knock out all my powerlines and bring my machine down before dhcpcd will give me problems, and I can hardly blame it for not working then.

The mere fact that it's still being improved astounds me. If only gnome had that sort of accountability..

----------

## UberLord

 :Cool:   :Embarassed:   :Cool: 

----------

## Incomplet

aand, now testing with no net.* scripts, and it looks to be working as advertised. At first I thought it hadn't worked, since with background and quiet I couldn't even see the entry in openrc. But no, fully automagical.

How on earth did you do that, anyway? Test driven development? Magic? (the only options I can come up with)

----------

## UberLord

Magic is not depending on the FOTM middleware. dhcpcd communicates only via libc and listens only via the kernel (ok, dhcpcd does have a udev plugin so that udev can do its pointless device naming). These channels of communication are defined by agreed standards, such as POSIX and in the case of Linux, netlink. But this is not magic, this is common sense.

From my Debian amd64 box

```

roy@uberpc:~/src/dhcpcd$ size /sbin/dhcpcd /sbin/dhclient /usr/sbin/NetworkManager

   text      data       bss       dec       hex   filename

 194982      1544       432    196958     3015e   /sbin/dhcpcd

1620973     24576     45264   1690813    19ccbd   /sbin/dhclient

1012178     22656      3016   1037850     fd61a   /usr/sbin/NetworkManager

```

And that's not including any GUI components. Magic  :Smile: 

----------

## VinzC

Since my favourite Troll has been invited (hehe  :Wink:  ) I'd just add onto the MS weirdness that I've always been amazed at why on Earth Microsoft decided to make interface precedence but *manual* (interfaces are sorted... alphabetically). We have the issue systematically at work when we receive pre-installed machines or when reinstalling them: wireless interfaces always take precedence over the wired interfaces and you have to manually reorder them, i.e. move the wired interface to the top of the list.

On Linux it is automatic. Besides, traffic automatically switches to the fastest interface when you plug the cable, no need to restart existing connections.

Magic sometimes relates to common sense.

----------

## Incomplet

@RM: Yeah, I've noticed that upstream sucks. It's really sad if the rest of gnu/linux could be that good if only certain people weren't trying to play monopolyOS. It's also amazing in a way, given all the limitations of C.

@Vinz: *sigh* dhcpcd also automatically stops the wireless card/driver in that situation too, doesn't it? What is it people have against sensibility, anyway?

----------

## UberLord

 *Incomplet wrote:*   

> @Vinz: *sigh* dhcpcd also automatically stops the wireless card/driver in that situation too, doesn't it? What is it people have against sensibility, anyway?

 

No, dhcpcd just changes the default route to go via wired.

If both are on the same subnet (which they really shouldn't be) then it will change the subnet route also on BSDs = on Linux there is no need thanks to routing metrics.

The only thing dhcpcd will stop is wpa_supplicant if the interface goes away.

----------

## charles17

 *VinzC wrote:*   

> Basic configuration
> 
> Install Roy Marples' dhcpcd with zeroconf support:
> 
> ```
> ...

 Zeroconf has gone (net-misc/dhcpcd-6.4.3).  Will this guide still work, even without zeroconf?  

Also, I am wondering why Gentoo handbook hasn't yet adopted this simplified setup.

----------

## xaviermiller

I use that setup without zeroconf support, and it rocks.

----------

## Dr.Willy

 *charles17 wrote:*   

> Also, I am wondering why Gentoo handbook hasn't yet adopted this simplified setup.

 

That is a good question.

----------

## xaviermiller

charles17 wireless problem moved here

----------

## VinzC

 *charles17 wrote:*   

> Zeroconf has gone (net-misc/dhcpcd-6.4.3).  Will this guide still work, even without zeroconf?

 

 *dhcp ebuild wrote:*   

> dhcpcd has zeroconf support active by default.

 

Means Zeroconf may have its USE flag gone but it's now built-in. It can be disabled with -L command line switch however. See http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/dhcpcd/dhcpcd-6.4.3.ebuild?view=markup .

----------

## charles17

Just put this wonderful guide on a wiki page. VPN interfaces and DNS resolution still missing there.

----------

## Dr.Willy

 *charles17 wrote:*   

> Just put this wonderful guide on a wiki page. VPN interfaces and DNS resolution still missing there.

 

Awesome.  :Very Happy: 

The part about wpa_supplicant's ctrl_interface (see https://forums.gentoo.org/viewtopic-p-7610948.html#7610948) should probably be mentioned.

----------

## VinzC

 *charles17 wrote:*   

> Just put this wonderful guide on a wiki page. VPN interfaces and DNS resolution still missing there.

 

 :Cool: 

As for VPN I kept having some weirdness (I've always used pon/poff for my VPN connections) along with openresolv and dnsmasq. Every now and then remote name servers failed to register with openresolv. From the couple of times I used pon/poff lately the problem doesn't happen.

This said VPN configuration is not that straightforward as there are many ways to implement a VPN connection, with or without flexible DNS resolution, with or without name caching, with or without mDNSResponder... My typical configuration is openresolv, dnsmasq and pptpclient plus some customized if-up scripts. So this is but as simple as this dhcpcd tutorial.

I would say VPN interfaces and dhcpcd are irrelevant in the end. Just teach dhcpcd to stay away from VPN interfaces (which configuration is usually dictated by the remote server) and that's it. Then you can plug in any VPN management you like. DNS resolution along with VPN is another dedicated topic IMHO.

----------

## charles17

 *Dr.Willy wrote:*   

> The part about wpa_supplicant's ctrl_interface (see https://forums.gentoo.org/viewtopic-p-7610948.html#7610948) should probably be mentioned.

 Done. Next question:

How are the network dependant services like ntpd, fetchmail sshd handled?  Would dhcpcd start/stop them or do we need to have them in runlevel default?

----------

## UberLord

 *charles17 wrote:*   

>  *Dr.Willy wrote:*   The part about wpa_supplicant's ctrl_interface (see https://forums.gentoo.org/viewtopic-p-7610948.html#7610948) should probably be mentioned. Done. Next question:
> 
> How are the network dependant services like ntpd, fetchmail sshd handled?  Would dhcpcd start/stop them or do we need to have them in runlevel default?

 

Not currently no.

Someone, like say an OpenRC dev needs to make a dhcpcd hook re-entrant so it goes inactive -> active ->inactive when no interfaces a running.

Still, for ntpd and sshd they generally bind to the wildcard address so it doesn't matter if there's a working IP or it changes, it still works.

----------

## charles17

 *UberLord wrote:*   

> Not currently no.
> 
> Someone, like say an OpenRC dev needs to make a dhcpcd hook re-entrant so it goes inactive -> active ->inactive when no interfaces a running.
> 
> Still, for ntpd and sshd they generally bind to the wildcard address so it doesn't matter if there's a working IP or it changes, it still works.

 I was wondering because debugging dhcpcd-hooks/50-ntp.conf gave me output with

```
++ eval service_condcommand ntpd restart '&'

+++ service_condcommand ntpd restart
```

But this seems not to be doing anything.

----------

## depontius

 *UberLord wrote:*   

>  *charles17 wrote:*    *Dr.Willy wrote:*   The part about wpa_supplicant's ctrl_interface (see https://forums.gentoo.org/viewtopic-p-7610948.html#7610948) should probably be mentioned. Done. Next question:
> 
> How are the network dependant services like ntpd, fetchmail sshd handled?  Would dhcpcd start/stop them or do we need to have them in runlevel default? 
> 
> Not currently no.
> ...

 

Especially on a dual-homed server, but sometimes even on my clients, I don't like to bind to the wildcard - I like to know where I'm listening.  I'm quite interested in better OpenRC support of this way of running dhcpcd.

----------

## UberLord

 *depontius wrote:*   

> Especially on a dual-homed server, but sometimes even on my clients, I don't like to bind to the wildcard - I like to know where I'm listening.  I'm quite interested in better OpenRC support of this way of running dhcpcd.

 

Silly question then - what is the expected result IF the IP address changes at all? I assume you have dhcpcd hooks in place to insert the IP to listen on into your service configs  :Wink: 

And if it doesn't change, why are you running a DHCP client?  :Smile: 

----------

## depontius

 *UberLord wrote:*   

>  *depontius wrote:*   Especially on a dual-homed server, but sometimes even on my clients, I don't like to bind to the wildcard - I like to know where I'm listening.  I'm quite interested in better OpenRC support of this way of running dhcpcd. 
> 
> Silly question then - what is the expected result IF the IP address changes at all? I assume you have dhcpcd hooks in place to insert the IP to listen on into your service configs 
> 
> And if it doesn't change, why are you running a DHCP client? 

 

I've done both, on different systems.  On my home systems I'm not fussy once I'm inside my LAN, so I let the wildcards happen.  However on my home LAN I use dhcp for central administration purposes.  My name/IP mapping is only in my BIND zone files, and my name/MAC mapping is only in my dhcpd.conf.  I can control all of that from my server, and clients remain dumb.  On my laptops I'm much fussier, and I tweak things quite a bit depending on what network I'm attached to.  The laptop runs the corporate image, and that means RH with network-manage, so I'm using those hooks.  (Though I did dual-boot Gentoo on the previous corporate laptop, before they changed the security rules, and then I used the dhcpcd hooks.)  Whenever I get my own personal laptop, I'll use the dhcpcd hooks again.

One side...  I'm being somewhat paranoid based on the network I connect to - on "unknown" networks I wind up with no listening ports other than dhcpcd itself.  But even whenI connect to my home or work networks, how do I know they're really my home or work networks, or someone setting up a dhcp server to deliver the expected IP, tricking me into starting some services?  I've not come up with a good way to handle this one that wouldn't take a bunch of software infrastructure.

----------

## UberLord

 *depontius wrote:*   

> One side...  I'm being somewhat paranoid based on the network I connect to - on "unknown" networks I wind up with no listening ports other than dhcpcd itself.  But even whenI connect to my home or work networks, how do I know they're really my home or work networks, or someone setting up a dhcp server to deliver the expected IP, tricking me into starting some services?  I've not come up with a good way to handle this one that wouldn't take a bunch of software infrastructure.

 

Uh, DHCP authentication? (not well supported by DHCP servers, but dhcpcd supports it).

http://tools.ietf.org/html/rfc3118

It's in the DHCPv6 standard as well which dhcpcd supports.

Maybe IEEE802.11 authentication on the switched port or WPA PSK?

All valid solutions.

----------

## depontius

 *UberLord wrote:*   

>  *depontius wrote:*   One side...  I'm being somewhat paranoid based on the network I connect to - on "unknown" networks I wind up with no listening ports other than dhcpcd itself.  But even whenI connect to my home or work networks, how do I know they're really my home or work networks, or someone setting up a dhcp server to deliver the expected IP, tricking me into starting some services?  I've not come up with a good way to handle this one that wouldn't take a bunch of software infrastructure. 
> 
> Uh, DHCP authentication? (not well supported by DHCP servers, but dhcpcd supports it).
> 
> http://tools.ietf.org/html/rfc3118
> ...

 

I can do stuff like that for my home network, and will look into it.  The corporate network is so silly-backwards you wouldn't believe it.  But it's their network, their laptop, their software, and they insist that I use it as provided.  Oh well.

----------

## steveL

 *UberLord wrote:*   

> Someone, like say an OpenRC dev needs to make a dhcpcd hook re-entrant so it goes inactive -> active ->inactive when no interfaces a running.

 

Hmm what do you want to happen? Also, I wish you were still in charge of openrc; I reviewed the commit history a while back, and it's gone completely downhill since you left. Some of the sh is simply painful to look at (as in: embarrassing), and there's been no other real code, apart from one patch from a user who like many others should have been nurtured into a developer on the project but wasn't. Oh an aborted attempt to remove an API, which I advised strongly against before it happened, and it was reverted a few weeks later: no other actual code, since you left. Disappointing, to say the least.

 *Quote:*   

> Still, for ntpd and sshd they generally bind to the wildcard address so it doesn't matter if there's a working IP or it changes, it still works.

 

Heh indeed. Funny how the old ideas still work.. just like a tap, or a plug still does the job. ;-)

----------

## UberLord

 *steveL wrote:*   

> Hmm what do you want to happen?

 

Me? Nothing, I'm not entirely sure of the usefulness of this feature.

You either have complex scripts to update the IP services bind to (heh, like my hook scripts in dhcpcd - good examples there!) or you have the IP hard coded and made the running of DHCP for central IP management kinda redundant.

Saying that, I have made this patch upstream:

http://roy.marples.name/projects/dhcpcd/ci/1113488b81673c23b3b079e1fc5ea6df5ffc0ee5?sbs=0

Which will aid the creation of a hook. I've even provided a rough idea of how it would look here:

https://bugs.gentoo.org/show_bug.cgi?id=522206#c1

 *Quote:*   

>  Also, I wish you were still in charge of openrc; I reviewed the commit history a while back, and it's gone completely downhill since you left. Some of the sh is simply painful to look at (as in: embarrassing), and there's been no other real code, apart from one patch from a user who like many others should have been nurtured into a developer on the project but wasn't. Oh an aborted attempt to remove an API, which I advised strongly against before it happened, and it was reverted a few weeks later: no other actual code, since you left. Disappointing, to say the least.
> 
>  *Quote:*   Still, for ntpd and sshd they generally bind to the wildcard address so it doesn't matter if there's a working IP or it changes, it still works. 
> 
> Heh indeed. Funny how the old ideas still work.. just like a tap, or a plug still does the job. 

 

Sorry that you think it's gone down hill, but I really don't have the time to maintain it anymore. All my free time goes into dhcpcd, dhcpcd-ui (working on a dhcpcd-qt port as we speak).

If you feel that passionate about it, then join the team and help out!

----------

## charles17

 *UberLord wrote:*   

> Saying that, I have made this patch upstream:
> 
> http://roy.marples.name/projects/dhcpcd/ci/1113488b81673c23b3b079e1fc5ea6df5ffc0ee5?sbs=0
> 
> Which will aid the creation of a hook. I've even provided a rough idea of how it would look here:
> ...

 Will this interrupt ("backgrounding") and reactivate those network dependant services like openrc/netifrc does?

Then those services would need to be in runlevel default (using "need net" or "use net")?

I'd like to try it but need some help.  What is the easiest way of emerging dhcpcd with this patch?

----------

## UberLord

 *charles17 wrote:*   

> I'd like to try it but need some help.  What is the easiest way of emerging dhcpcd with this patch?

 

Install the 9999 version.

That will also install Fossil so you can pull the latest dhcpcd code from my repository.

----------

## charles17

 *UberLord wrote:*   

> Install the 9999 version.
> 
> That will also install Fossil so you can pull the latest dhcpcd code from my repository.

 Tried that but getting errors, see pastebin. How to proceed?

----------

## UberLord

Can you pastebin your copy of /usr/include/linux/if_link.h please?

----------

## charles17

Here comes pastebin of my if_link.h.

----------

## UberLord

Fixed. Maybe one day Linux developers will actually allow #ifdef to work on newly added code, but I'm not holding my breath.

----------

## charles17

Thanks for your fast action.  Compilation works and I did a first test with "99-openrc".  

```
set -x

# https://bugs.gentoo.org/show_bug.cgi?id=522206#c1

if $if_oneup && if_ipwaited then;

   mark_service_started dhcpcd

else

   mark_service_inactive dhcpcd

fi
```

What is that syntax error it shows me? *Quote:*   

> $ su -c "dhcpcd -dB"
> 
> Password: 
> 
> dhcpcd[6481]: version 6.4.3 starting
> ...

 

----------

## UberLord

 *charles17 wrote:*   

> Thanks for your fast action.  Compilation works and I did a first test with "99-openrc".  
> 
> ```
> set -x
> 
> ...

 

Try this

```
if $if_oneup && if_ipwaited; then

   mark_service_started dhcpcd

else

   mark_service_inactive dhcpcd

fi
```

Notice the position of the ;

----------

## charles17

That one error has gone. But how to deal with the following? *Quote:*   

> $ su -c "dhcpcd -DB"
> 
> Password: 
> 
> dhcpcd[7566]: version 6.4.3 starting
> ...

 

----------

## UberLord

Maybe the mark_service foo isn't in $PATH?

Try appending the path to them where it is

/lib/rc/sbin/mark_service_inactive dhcpcd

----------

## charles17

Much better, with 

```
if $if_oneup && if_ipwaited; then

        /lib/rc/sbin/mark_service_started dhcpcd

else

        /lib/rc/sbin/mark_service_inactive dhcpcd

fi
```

I get some problem with if_ipwaited and if_disable_autolinklocal *Quote:*   

> $ su -c "dhcpcd -dB"
> 
> Password: 
> 
> dhcpcd[10816]: version 6.4.3 starting
> ...

 

----------

## UberLord

 *charles17 wrote:*   

> Much better, with 
> 
> ```
> if $if_oneup && if_ipwaited; then
> 
> ...

 

```
if $if_oneup && $if_ipwaited; then
```

Notice the $ before each variable name

if_disable_autolinklocal: This is reported because your kernel is too old for the feature and it's only reported when debugging is enabled.

You should be good to go now  :Smile: 

----------

## charles17

Thanks so much. Starting manually seems ok now. *Quote:*   

> $ su -c "dhcpcd -dB"
> 
> Password: 
> 
> dhcpcd[3494]: version 6.4.3 starting
> ...

 

When I press the hardware rfkill button on this laptop I get *Quote:*   

> dhcpcd[3494]: wlp8s0: dhcp if_readrawpacket: Network is down
> 
> dhcpcd[3494]: wlp8s0: carrier lost
> 
> dhcpcd[3494]: wlp8s0: executing `/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER
> ...

 But it should have only stopped without starting again. 

The same button again for restarting wireless *Quote:*   

> dhcpcd[3494]: wlp8s0: carrier acquired
> 
> dhcpcd[3494]: wlp8s0: if_disable_autolinklocal: Invalid argument
> 
> dhcpcd[3494]: wlp8s0: executing `/lib/dhcpcd/dhcpcd-run-hooks' CARRIER
> ...

 

----------

## UberLord

That looks ok to me. What problem do you see?

----------

## charles17

 *UberLord wrote:*   

> That looks ok to me. What problem do you see?

 From a powersaving perspective I don't like network dependant services running when network is not available.

----------

## UberLord

 *charles17 wrote:*   

>  *UberLord wrote:*   That looks ok to me. What problem do you see? From a powersaving perspective I don't like network dependant services running when network is not available.

 

I'm unsure what you mean. the hook script has marked dhcpcd as inactive, so either one of the following is true

1) The dhcpcd service does not provide net (the default one does)

2) Something else is providing net and is active

3) There's a bug

I'll try and look into it later

----------

## charles17

 *UberLord wrote:*   

> I'm unsure what you mean. the hook script has marked dhcpcd as inactive, 

 So far it's ok for me. I can see dhcpcd marked inactive. But ntpd is still running.

 *UberLord wrote:*   

> so either one of the following is true
> 
> 1) The dhcpcd service does not provide net (the default one does)
> 
> 2) Something else is providing net and is active

 How could I check if and how net is provided?

Also, I am not sure about the correct settings of these parameters */etc/rc.conf wrote:*   

> rc_depend_strict="NO"

  */etc/conf.d/ntpd wrote:*   

> # rc_need="net"

 

----------

## UberLord

There's a few bugs with OpenRC and the dhcpcd init script which stop the hook from running.

I've updated bug #522206 with the information and we should continue any discussion there.

----------

## steveL

 *UberLord wrote:*   

>  *steveL wrote:*   Hmm what do you want to happen? 
> 
> Me? Nothing, I'm not entirely sure of the usefulness of this feature.
> 
> You either have complex scripts to update the IP services bind to (heh, like my hook scripts in dhcpcd - good examples there!) or you have the IP hard coded and made the running of DHCP for central IP management kinda redundant.

 

Well there needs to be some sort of event-handling at the init-manager side, which has come up in other contexts too, so I'm trying to get a grasp of just what is essential and what isn't. I've consistently advocated for using dhcpcd to handle the netlink, so the first sounds better to me: no complexity til the admin explicitly specifies it, at which point it's their script on their machine, and not our problem ;)

 *Quote:*   

> Saying that, I have made this patch upstream:
> 
> http://roy.marples.name/projects/dhcpcd/ci/1113488b81673c23b3b079e1fc5ea6df5ffc0ee5?sbs=0
> 
> Which will aid the creation of a hook. I've even provided a rough idea of how it would look here:
> ...

 

Ah thanks; commented on the sh. I'd want to tweak that test a bit, codewise, though the compiler may do it for you, there's no guarantee; ie test the DHCPCD_WAITIP | DHCPCD_WAITIP4 | DHCPCD_WAITIP6 bits first.

 *Quote:*   

> Sorry that you think it's gone down hill, but I really don't have the time to maintain it anymore. All my free time goes into dhcpcd, dhcpcd-ui (working on a dhcpcd-qt port as we speak).

 

Eh, no bother, pretty much what I expected; istr you saying sth similar a few years ago. Just wish it wasn't being left to languish, as it'll bitrot at this rate. Mostly what the current "upstream" seems passionate about is sucking up to systemd to get in with the "big boys"; openrc is just a step imo; it's not being crafted any more, in the history I reviewed at least. (Everything from about 6-9 months ago, back to when you first started: I had to go back just to escape the crap, to reassure myself it wasn't your output.)

 *Quote:*   

> If you feel that passionate about it, then join the team and help out!

 

Blimey tried that; I guess I was spoilt by hanging out in #-portage for all these years; it's amazing the difference a good project lead makes.. anyhow let's not get into that discussion as it's not cogent to forward progress. If I were to sort anything with openrc at this point, I'd have to go back to your days, and filter out the crappy commits since, and add the bits they were trying to fix, only without the amateur-hour Gentoo-lol bashish, so that's not going to happen too soon, given current commitments. But it will happen at some point, since we need the software. *shrug* not your problem.

I'm glad you're still about though, and look forward to scripting with dhcpcd on my next install (after I sort this toolchain nonsense out.)

----------

## charles17

 *Dr.Willy wrote:*   

>  *charles17 wrote:*   Also, I am wondering why Gentoo handbook hasn't yet adopted this simplified setup. 
> 
> That is a good question.

 Just comparing the handbook

https://wiki.gentoo.org/wiki/Complete_Handbook/Configuring_the_system#Networking_information

with what's so far in

https://wiki.gentoo.org/wiki/Network_management_using_DHCPCD

the second one does not mention static IP addresses.

Could we handle static IP addresses without netifrc?  If so, how is the setup?

And, when will one ever need a static IP address?

----------

## steveL

 *charles17 wrote:*   

> Could we handle static IP addresses without netifrc?  If so, how is the setup?
> 
> And, when will one ever need a static IP address?

 

I'm pretty sure that was discussed earlier in the thread, as it was something I asked about.

On your second point, anyone on a LAN, not using a laptop or other mobile device, can easily use a static IP.

----------

## charles17

 *steveL wrote:*   

>  *charles17 wrote:*   Could we handle static IP addresses without netifrc?  If so, how is the setup?
> 
> And, when will one ever need a static IP address? 
> 
> I'm pretty sure that was discussed earlier in the thread, as it was something I asked about.

 Got it

https://wiki.gentoo.org/wiki/Network_management_using_DHCPCD#Static_IP_address

----------

## Yamakuzure

This method works great for me.

Unfortunately I have one issue:

When I wakeup my laptop from suspend, wifi is not working. I have a little script that removes the wl module (from net-wireless/broadcom-sta), reinserts it and uses rfkill, ifconfig and iw to set things up. But after a suspend, dhcpcd does not start wpa_supplicant for it automatically. Even restarting dhcpcd does not help, I have to manually start /etc/init.d/wpa_supplicant.

Any idea what the cause might be?

Oh, I have the following in dhcpcd.conf : 

```
 ~ $ grep -P "^[^#]\S" /etc/dhcpcd.conf

allowinterfaces eth* wlan*

denyinterfaces ppp* vmnet*

hostname

duid

persistent

option rapid_commit

option domain_name_servers, domain_name, domain_search, host_name

option classless_static_routes

option ntp_servers

option interface_mtu

require dhcp_server_identifier

slaac private

nohook lookup-hostname

interface lo

static ip_adress=127.0.0.1/8

interface wlan1

env ifwireless=1
```

----------

## UberLord

 *Yamakuzure wrote:*   

> When I wakeup my laptop from suspend, wifi is not working. I have a little script that removes the wl module (from net-wireless/broadcom-sta), reinserts it and uses rfkill, ifconfig and iw to set things up. But after a suspend, dhcpcd does not start wpa_supplicant for it automatically. Even restarting dhcpcd does not help, I have to manually start /etc/init.d/wpa_supplicant.
> 
> Any idea what the cause might be?

 

dhcpcd only starts wpa_supplicant if it's not running and even then only during reconfigure or preinit phases.

Now, if you remove the kernel module, that implies the interface will vanish (if it removes the interface).

If dhcpcd spots this, it will stop wpa_supplicant.

When the kernel module is re-inserted, dhcpcd will spot (if it adds an interface) this, trigger preinit and start wpa_supplicant.

Have to ask why do this anyway?  Just keep the module and don't rfkill on suspend?

 *Quote:*   

> 
> 
> Oh, I have the following in dhcpcd.conf : 
> 
> ```
> ...

 

Going to assume that the interface it will add is allowed.

 *Quote:*   

> 
> 
> ```
> 
> interface wlan1
> ...

 

You shouldn't need that with dhcpcd-6.4.5

----------

## Yamakuzure

 *UberLord wrote:*   

> dhcpcd only starts wpa_supplicant if it's not running and even then only during reconfigure or preinit phases.
> 
> Now, if you remove the kernel module, that implies the interface will vanish (if it removes the interface).
> 
> If dhcpcd spots this, it will stop wpa_supplicant.
> ...

 That is the thing. The interface vanishes, re-appears, no wpa_supplicant is running, but dhcpcd won't start it for the interface. Even when dhcpcd itself is started. *UberLord wrote:*   

> Have to ask why do this anyway?  Just keep the module and don't rfkill on suspend?

 There is a bug that causes the driver to fail to connect anywhere when the card came out of resume. rmmod+insmod is the "official" workaround. *UberLord wrote:*   

> Going to assume that the interface it will add is allowed.
> 
>  *Quote:*   
> 
> ```
> ...

 I have updated today after spotting the update. Haven't tried out whether the issue might be fixed completely with the new version. I'll reply to that once I have tested it.

----------

## UberLord

I think the clue is that you're starting wpa_supplicant via /etc/init.d

With everything working, do this

```

dhcpcd -x

pkill wpa_supplicant

dhcpcd -dB
```

Watch in the console.

If you don't get the message that dhcpcd is starting wpa_supplicant then something is wrong with your setup - probably the wpa_supplicant.conf dhcpcd is using.

----------

## charles17

 *UberLord wrote:*   

> With everything working, do this
> 
> ```
> 
> dhcpcd -x
> ...

 

Tried watching the startup procedure with wpa_supplicat and dhcpcd killed. So just only

```
dhcpcd -dB
```

And everything runs fine.  But what is "if_disable_autolinklocal: Invalid argument"? 

```
$ su -c "dhcpcd -dB"

Password: 

dhcpcd[23772]: version 6.4.5 starting

dhcpcd[23772]: udev: starting

dhcpcd[23772]: dev: loaded udev

dhcpcd[23772]: enp2s14: if_disable_autolinklocal: Invalid argument

dhcpcd[23772]: wlp8s0: if_disable_autolinklocal: Invalid argument

dhcpcd[23772]: wlp8s0: adding address fe80::b7ef:4566:e492:4625

dhcpcd[23772]: wlp8s0: vltime infinity, pltime infinity

dhcpcd[23772]: enp2s14: executing `/lib/dhcpcd/dhcpcd-run-hooks' PREINIT

dhcpcd[23772]: enp2s14: executing `/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER

dhcpcd[23772]: wlp8s0: executing `/lib/dhcpcd/dhcpcd-run-hooks' PREINIT

dhcpcd[23824]: wlp8s0: starting wpa_supplicant

ntpd             | * Stopping ntpd ... [ ok ]

ntpd             | * Starting ntpd ... [ ok ]

dhcpcd[23772]: wlp8s0: executing `/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER

dhcpcd[23772]: no interfaces have a carrier

dhcpcd[23772]: enp2s14: waiting for carrier

dhcpcd[23772]: wlp8s0: waiting for carrier

dhcpcd[23772]: wlp8s0: carrier acquired

dhcpcd[23772]: wlp8s0: if_disable_autolinklocal: Invalid argument

dhcpcd[23772]: wlp8s0: executing `/lib/dhcpcd/dhcpcd-run-hooks' CARRIER

dhcpcd[23772]: DUID 00:01:00:01:0f:02:bb:59:00:1b:77:b1:c8:8e

dhcpcd[23772]: wlp8s0: IAID 77:b1:c8:8e

dhcpcd[23772]: wlp8s0: delaying IPv6 router solictation for 0.5 seconds

dhcpcd[23772]: wlp8s0: delaying IPv4 for 0.3 seconds

dhcpcd[23772]: wlp8s0: reading lease `/var/lib/dhcpcd/dhcpcd-wlp8s0.lease'

dhcpcd[23772]: wlp8s0: rebinding lease of 192.168.178.23

dhcpcd[23772]: wlp8s0: sending REQUEST (xid 0xdec22e04), next in 4.3 seconds

dhcpcd[23772]: wlp8s0: acknowledged 192.168.178.23 from 192.168.178.1

dhcpcd[23772]: wlp8s0: leased 192.168.178.23 for 864000 seconds
```

----------

## UberLord

 *charles17 wrote:*   

> startup procedure with wpa_supplicat and dhcpcd killed. So just only
> 
> ```
> dhcpcd -dB
> ```
> ...

 

It means you kernel is too old for that feature.

Due to the wisdom the of the linux kernel devs, we have no way of knowing if it exists at compile time so we force the value but only show an error with debugging enabled.

OK, so it does appear to be working. Could be a race somewhere. Try changing your kernel hack to this

```
rmmod module

sleep 3

insmod module
```

Or this

```

dhcpcd -x

rmmod module

insmod module

dhcpcd -d

```

----------

## Yamakuzure

 *Yamakuzure wrote:*   

>  *UberLord wrote:*   Have to ask why do this anyway?  Just keep the module and don't rfkill on suspend? There is a bug that causes the driver to fail to connect anywhere when the card came out of resume. rmmod+insmod is the "official" workaround. *UberLord wrote:*   Going to assume that the interface it will add is allowed.
> 
>  *Quote:*   
> 
> ```
> ...

 One try with the new version yesterday. After wakeup the network status applet showed that the device does not exist (module not loaded), after a second it changed to "not connected", a second later it changed to "connected". Tried a ping on google, it worked.

Wow. That new version of dhcpcd really seemed to do do the trick! Thank you very much!

----------

## VinzC

I have an issue here. I have gone through a huge upgrade (stayed months without upgrading) and a lot of packages have been touched so I have really no idea what causes this. Anyway.

I'm running kernel 3.16.6, OpenRC 0.12.4 (without netifrc) and dhcpcd 6.4.7. I noticed when the computer rebooted the loopback interface is down (causing a few services not to start) and I have to either enable /etc/init.d/loopback (which I'd like to avoid) or bring lo up manually and restart all depending services... which I'd like to avoid as well  :Very Happy:  . Is there a reason dhcpcd would not bring up lo?

----------

## UberLord

 *VinzC wrote:*   

> I have an issue here. I have gone through a huge upgrade (stayed months without upgrading) and a lot of packages have been touched so I have really no idea what causes this. Anyway.
> 
> I'm running kernel 3.16.6, OpenRC 0.12.4 (without netifrc) and dhcpcd 6.4.7. I noticed when the computer rebooted the loopback interface is down (causing a few services not to start) and I have to either enable /etc/init.d/loopback (which I'd like to avoid) or bring lo up manually and restart all depending services... which I'd like to avoid as well  . Is there a reason dhcpcd would not bring up lo?

 

dhcpcd does not bring up a loopback interface unless instructed to.

EDIT: To be fair, I've never tested it bringing one up either

----------

## VinzC

 *UberLord wrote:*   

> dhcpcd does not bring up a loopback interface unless instructed to.

 

Thanks, Roy. I must confess I crawled the man page several times but couldn't find a hint. Is it through a hook of some sort?

 *UberLord wrote:*   

> EDIT: To be fair, I've never tested it bringing one up either

 

I might be soon  :Very Happy:  .

----------

## UberLord

try this

```

allowinterfaces lo *

interface lo

static ip_address=127.0.0.1/8
```

----------

## VinzC

Trying it right now. Back in a minute...

EDIT: Back! Roy, I owe you some beercoins. Thanks a lot, man   :Cool:  .

----------

## steveL

Heh guess you can edit this post to say "yes" then?

----------

## Dr.Willy

And http://wiki.gentoo.org/wiki/Dhcpcd#Migration_from_Gentoo_net..2A_scripts

----------

## UberLord

 *steveL wrote:*   

> Heh guess you can edit this post to say "yes" then?

 

Well, he needs to edit it to include the allowinterfaces line as well...

----------

## Dr.Willy

 *UberLord wrote:*   

> Well, he needs to edit it to include the allowinterfaces line as well...

 

2 questions:

- what is the default value for allowinterfaces?

- why doesn't configuring an interface via 'interface foo' add it to the allowed interfaces?

----------

## UberLord

 *Dr.Willy wrote:*   

>  *UberLord wrote:*   Well, he needs to edit it to include the allowinterfaces line as well... 
> 
> 2 questions:
> 
> - what is the default value for allowinterfaces?
> ...

 

The default value for allowinterfaces is nothing, which is to say allow all interfaces except for loopback and pointopoint interfaces.

As to the latter, well that's a good question.

I suppose that if allowinterfaces is NOT defined in the config, we could append it in code.

----------

## Dr.Willy

 *UberLord wrote:*   

> The default value for allowinterfaces is nothing, which is to say allow all interfaces except for loopback and pointopoint interfaces.

 

So is 'allowinterfaces lo *' actually equivalent to just adding lo or does it also add pointtopoint interfaces?

 *UberLord wrote:*   

> I suppose that if allowinterfaces is NOT defined in the config, we could append it in code.

 

Does that even make sense at all? I mean creating a specific configuration for an interface while not letting dhcpcd discover it?

Because otherwise I'd say add it to allowinterfaces unless it's in denyinterfaces.

----------

## UberLord

 *Dr.Willy wrote:*   

>  *UberLord wrote:*   The default value for allowinterfaces is nothing, which is to say allow all interfaces except for loopback and pointopoint interfaces. 
> 
> So is 'allowinterfaces lo *' actually equivalent to just adding lo or does it also add pointtopoint interfaces?
> 
> 

 

Heh, yeah it does by virtue of the *

 *Quote:*   

>  *UberLord wrote:*   I suppose that if allowinterfaces is NOT defined in the config, we could append it in code. 
> 
> Does that even make sense at all? I mean creating a specific configuration for an interface while not letting dhcpcd discover it?
> 
> Because otherwise I'd say add it to allowinterfaces unless it's in denyinterfaces.

 

Yes in my mind it does make sense.

Take apache, or any server daemon, with allow/deny directives. They override any other setting. dhcpcd takes the same approach.

----------

## Dr.Willy

 *UberLord wrote:*   

> Heh, yeah it does by virtue of the *

 

Sooo … 'allowinterfaces lo *' actually does the same as 'allowinterfaces *'?

----------

## UberLord

Yes it does.

I could have worded it better I suppose, maybe something this like:

Ensure that lo appears as a valid match in the allowinterfaces directive.

But I also wanted to give a working code example.

----------

## steveL

Hmm I agree it should just add a configured interface; it seems odd to have allow everything, and really I'd just want whatever I configure as root to be added to the set, without needing to do anything else.

Apologies if I'm missing some subtlety.

----------

## VinzC

 *steveL wrote:*   

> Heh guess you can edit this post to say "yes" then?

 

I forgot about that post but anyway the first post in this topic, which is *the* reference, has already been updated.

 *steveL wrote:*   

> Hmm I agree it should just add a configured interface; it seems odd to have allow everything, and really I'd just want whatever I configure as root to be added to the set, without needing to do anything else.
> 
> Apologies if I'm missing some subtlety.

 

Well, not sure if this was the intent but let's not confuse *configuring* an interface and *bring it up/down*, which aren't the same thing. To me at least. As a matter of fact, leaving allowinterfaces blank doesn't stop dhcpcd from configuring the interface. The directive must include lo to also bring it up.

----------

## UberLord

 *steveL wrote:*   

> Hmm I agree it should just add a configured interface; it seems odd to have allow everything, and really I'd just want whatever I configure as root to be added to the set, without needing to do anything else.
> 
> Apologies if I'm missing some subtlety.

 

This has now been implemented.

However, allowinterfaces is still respected above everything else.

----------

## Schnulli

VinzC ......pssssst

have a look at RedHat and CentOS scripts "ifnetup and ifnetdown"

they usually work fine and might help you and us all  :Wink: 

----------

## VinzC

 *Schnulli wrote:*   

> VinzC ......pssssst
> 
> have a look at RedHat and CentOS scripts "ifnetup and ifnetdown"
> 
> they usually work fine and might help you and us all 

 

 :Laughing: 

I prefer dhcpcd's simplicity though. One script, one config, fits most cases. I know CentOS/RH network management but I still find it too complex for the simplest setup.

----------

## Schnulli

the ifnetup and ifnetdown scripts are a good example to have a cron checking if or dont connected ^^ thats all, complex yes, but works.....

----------

## steveL

 *steveL wrote:*   

> I'd just want whatever I configure as root to be added to the set, without needing to do anything else.

 

 *UberLord wrote:*   

> This has now been implemented.
> 
> However, allowinterfaces is still respected above everything else.

 

Ah thanks, nice one :-)  I take it you mean for deny?

 *Schnulli wrote:*   

> the ifnetup and ifnetdown scripts are a good example to have a cron checking if or dont connected ^^ thats all, complex yes, but works.....

 

It's better to post a link to a [url], usually from a version-control web-interface, if you want people to look at stuff.

----------

## charles17

 *Dr.Willy wrote:*   

>  *charles17 wrote:*   Also, I am wondering why Gentoo handbook hasn't yet adopted this simplified setup. 
> 
> That is a good question.

 

Just opened bug 534752.

----------

## v_andal

One question. I have network filesystem which is supposed to be mounted on boot. It is listed in /etc/fstab. Things are working fine when I use net.* scripts. Without them, the filesystem is not mounted. I have to do it manually. Is there any simple way to tell dhcpcd to do it? I guess, I can create some script that dhcpcd executes when network is up, but rather relied on existing solution.

----------

## charles17

 *v_andal wrote:*   

> One question. I have network filesystem which is supposed to be mounted on boot. It is listed in /etc/fstab. Things are working fine when I use net.* scripts. Without them, the filesystem is not mounted. I have to do it manually. Is there any simple way to tell dhcpcd to do it? I guess, I can create some script that dhcpcd executes when network is up, but rather relied on existing solution.

 There is /etc/init.d/netmount which is part of openrc.

I have rpcbind and fetchmail being started after dhcpcd comes up. And I guess it sould work for netmount as well. 

https://wiki.gentoo.org/wiki/Network_management_using_DHCPCD/Network_dependant_services

----------

## steveL

Just linking here to keep it all in one place; new wpa_supplicant should be started as a service.

Note that it's not in ebuild form yet, so just a heads-up.

----------

## P.Kosunen

Do i put static IPv6 gateway just after IPv4 gateway to "static routers" line in dhcpcd.conf or is it even supported?

----------

## UberLord

While the setting of a static IPv6 address is supported, routes are not.

You'll still need something broadcasting RA's.

----------

## P.Kosunen

 *UberLord wrote:*   

> While the setting of a static IPv6 address is supported, routes are not.
> 
> You'll still need something broadcasting RA's.

 

```
ip -family inet6 route add default via [IPv6-GW] dev eth0
```

Ok, dhcpcd.conf with static IPv6 address and noipv6rs option with above ip command at local startup script seem keep it working. With ipv6rs enabled it only works for a while, apparently some problem in OVH/Kimsufi network configuration.

----------

## gabrielg

Hi!

Some advice sought on this matter: I am using iwd (with its native DHCP client) and dhcpcd for ethernet networking management.  It all works well, and much better than my last set up (wpa_supplicant, netifrc, ifplugd).

However, link detection stops working under a specific scenario: if my system is plugged in on ethernet, I suspend to disk, unplug and then resume the system, dhcpcd does not detect that the ethernet link disappeared and thus the routes stay  and networking doesn't work until I do a rebind or plain dhcpcd restart.  Wireless works, but with ethernet routes, it doesn't get me anywhere.

Is there any config setting I may be missing? If not, what is the best way to execute a dhcpcd --rebind after resuming my system, since I don't see any hooks for s2disk/resume?

Thanks!

----------

## Hu

How are you triggering the suspend-to-disk?  My first suggestion would be to use the wrapper script /usr/bin/hibernate (from sys-power/hibernate-script) to initiate the suspend.  It can be configured to use in-kernel hibernate, s2disk hibernate, or tuxonice hibernate.  The configuration file can also specify shell snippets to run on suspend or resume, which you could use to explicitly execute the rebind operation.

----------

## gabrielg

Thanks, Hu - I'm triggering s2disk with elogind. I was looking into your proposed solution until I bumped into this: https://wiki.gentoo.org/wiki/Elogind#Hook_scripts_to_be_run_when_suspending.2Fhibernating_and.2For_when_resuming.2Fthawing

So... I will try that before exploring the hibernate-script. Two options is plenty! Thanks a lot!

----------

