# [solved] dhcp during bootup...

## disi

How do I make openrc not get stuck on dhcp during boot? It waits ~60 seconds for an IP and then sometimes doesn't even get one in time, which doesn't prevent the depending services from running.

I tried using dhcpcd

```
dhcpcd_eth0="-t 10"
```

which doesn't change anything.

I tried using ifplugd (similar netplug):

```
ifplugd_eth0=""
```

Even parallel startup with openrc, it waits for ~60 seconds.

Then there is this strict thing in /etc/rc.conf which I didn't want to change.

What I would like is to start dhcpcd as background service, which it does anyway, and then carry on with the boot process. The laptop is usually booted once a day, but it still bothers me (without dhcp I could drop boot time into gdm to ~10 seconds).   :Confused: 

----------

## khayyam

disi ...

If your dhcp takes > 60 seconds then there seems to be some issue on the network and/or some issue with the driver ... however, please post your /etc/conf.d/net and the output of "awk '/Ethernet/,/Kernel/' <(lspci -k)" and any thing from dmesg relating to eth0 and the driver in question.

best ... khay

----------

## MacGyver031

 *Quote:*   

> How do I make openrc not get stuck on dhcp during boot?

 

If you 

```
emerge netplug
```

 then dhcpcd will run in the background while the system starts up. Be aware that services depending on network will not be started until the network is up.

BR.

----------

## disi

```
disi-bigtop ~ # awk '/Ethernet/,/Kernel/' <(lspci -k)

03:00.0 Ethernet controller: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller (rev 05)

   Subsystem: CLEVO/KAPOK Computer Device 5102

   Kernel driver in use: jme
```

It has some issue to negotiate between 100 and 1000 mbit, this is since forever.

here the gap for dhcpcd to boot up:

```
Jul 16 16:58:40 disi-bigtop kernel: udlfb: DisplayLink USB device /dev/fb1 attached. 800x600 resolution. Using 1880K framebuffer memory

Jul 16 16:58:40 disi-bigtop kernel: firewire_core: created device fw0: GUID eaf49cb5f5900058, S400

Jul 16 16:58:40 disi-bigtop kernel: EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

Jul 16 16:58:40 disi-bigtop dhcpcd[8027]: version 5.5.6 starting

Jul 16 16:58:40 disi-bigtop dhcpcd[8027]: all: not configured to accept IPv6 RAs

Jul 16 16:58:41 disi-bigtop kernel: jme 0000:03:00.0: irq 54 for MSI/MSI-X

Jul 16 16:58:41 disi-bigtop kernel: jme 0000:03:00.0: eth0: Link is down

Jul 16 16:58:41 disi-bigtop dhcpcd[8027]: wlan0: up_interface: Operation not possible due to RF-kill

Jul 16 16:58:41 disi-bigtop kernel: jme 0000:03:00.0: eth0: Link is down

Jul 16 16:58:41 disi-bigtop dhcpcd[8027]: eth0: broadcasting for a lease

Jul 16 16:58:41 disi-bigtop dhcpcd[8027]: wlan0: waiting for carrier

Jul 16 16:59:05 disi-bigtop kernel: jme 0000:03:00.0: eth0: Link is up at ANed: 100 Mbps, Full-Duplex, MDI

Jul 16 16:59:10 disi-bigtop dhcpcd[8027]: eth0: offered 192.168.0.43 from 192.168.0.254

Jul 16 16:59:10 disi-bigtop dhcpcd[8027]: eth0: acknowledged 192.168.0.43 from 192.168.0.254

Jul 16 16:59:11 disi-bigtop dhcpcd[8027]: eth0: checking for 192.168.0.43

Jul 16 16:59:11 disi-bigtop dhcpcd[8027]: timed out

Jul 16 16:59:11 disi-bigtop dhcpcd[8027]: allowing 8 seconds for IPv4LL timeout

Jul 16 16:59:16 disi-bigtop dhcpcd[8027]: eth0: leased 192.168.0.43 for 600 seconds

Jul 16 16:59:16 disi-bigtop dhcpcd[8027]: forked to background, child pid 8103

Jul 16 16:59:16 disi-bigtop kernel: NET: Registered protocol family 10

Jul 16 16:59:16 disi-bigtop rpc.statd[8146]: Version 1.2.6 starting

Jul 16 16:59:16 disi-bigtop rpc.statd[8146]: Flags: TI-RPC 

Jul 16 16:59:16 disi-bigtop rpc.statd[8146]: Running as root.  chown /var/lib/nfs to choose different user

Jul 16 16:59:16 disi-bigtop sm-notify[8162]: Version 1.2.6 starting

Jul 16 16:59:17 disi-bigtop ntpd[8206]: ntpd 4.2.6p5@1.2349-o Mon Jun 25 17:24:53 UTC 2012 (1)

```

OK, its 'only' 36 seconds   :Embarassed: 

I tried netplug before but didn't help. I remember what was different before, I used wicd which just booted up no matter what and was then looking for an IP   :Idea: 

----------

## khayyam

 *disi wrote:*   

> It has some issue to negotiate between 100 and 1000 mbit, this is since forever.

 

disi ... yes, and I assume the link is 100mb (switch or hub). BTW, you didn't post you conf.d/net ..

 *disi wrote:*   

> 
> 
> ```
> Jul 16 16:58:40 disi-bigtop dhcpcd[8027]: version 5.5.6 starting
> 
> ...

 

Am I understanding that you run dhcpcd from default? It seems to start before the interface is brought up ... please try removing it and adding the following to conf.d/net ...

```
modules_eth0="!plug dhcpcd"

config_eht0="dhcp"

dhcpcd_eth0="-t 10"

enable_ipv6_eth0="false"
```

Then add net.eth0 to the default runlevel (if it's not already)

... also, what happens if you run the following:

```
% ifconfig eth0 down

% ifconfig eth0 up
```

or better ... if you have sys-apps/iproute2 installed:

```
% ip link set eth0 down

% ip link set eth0 up
```

... does it also hang?

best ... khay

----------

## disi

Hey khayyam, just plugged that into my /etc/conf.d/net

Thanks for the config, I cannot test though   :Confused:  Just so happy for my FreeBSD upgrade  :Smile: 

p.s. drunk... follow up tomorrow  :Smile: 

----------

## disi

 *khayyam wrote:*   

>  *disi wrote:*   It has some issue to negotiate between 100 and 1000 mbit, this is since forever. 
> 
> disi ... yes, and I assume the link is 100mb (switch or hub). BTW, you didn't post you conf.d/net ..

 

nope, its a gigabit switch... (the FreeBSD box and a Toshiba netbook work just fine on it with 1000)

 *khayyam wrote:*   

> 
> 
>  *disi wrote:*   
> 
> ```
> ...

 

nope, AFAIR this was with a blank /etc/conf.d/net and dhcpcd in no runlevel, the bootscripts fall back to dhcp automatically.

 *khayyam wrote:*   

> 
> 
> ```
> modules_eth0="!plug dhcpcd"
> 
> ...

 

going to test this later... but the manual linking to net.lo is usually not needed anymore, so net.eth0 should not be in any runlevel but hotplug itself...

----------

## khayyam

 *disi wrote:*   

>  *khayyam wrote:*   [...] and I assume the link is 100mb (switch or hub). 
> 
> nope, its a gigabit switch... (the FreeBSD box and a Toshiba netbook work just fine on it with 1000)

 

disi ... auto-negotiation is a requirement for gigabit ethernet. The most obvious reason for it failing is the cable, have you tried swapping it out for one known to work?   

 *disi wrote:*   

>  *khayyam wrote:*   Am I understanding that you run dhcpcd from default? It seems to start before the interface is brought up ... please try removing it and adding the following to conf.d/net ... 
> 
> nope, AFAIR this was with a blank /etc/conf.d/net and dhcpcd in no runlevel, the bootscripts fall back to dhcp automatically.

 

OK, then dhcpcd is started by another service that requires networking (as I remember NTP was in default).

 *disi wrote:*   

>  *khayyam wrote:*   Then add net.eth0 to the default runlevel (if it's not already) 
> 
> going to test this later... but the manual linking to net.lo is usually not needed anymore, so net.eth0 should not be in any runlevel but hotplug itself...

 

Your trusting that hotplug will do the right thing ... and note "[b]y default we do not allow hotplugging" (/etc/rc.conf) ... I suggest that you do add net.eth0 to default ...

best ... khay

----------

## disi

Different cable, same result (patch cat5e)

I added dhcpcd to the default runlevel etc., all the same stuff, the 36 seconds seem consistent, not a second more or less each boot.

Actual does Gnome3 use NetworkManager? Maybe I should start that daemon to the runlevel...

```
networkmanager? ( >=net-misc/networkmanager-0.8.999[introspection] )
```

  :Idea: 

And something like:

```
rc_hotplug="!net.*"
```

in the /etc/rc.conf. Just in case, but I can confirm what you quoted out of the config about we do not hotplug brabra...

----------

## khayyam

 *disi wrote:*   

> I added dhcpcd to the default runlevel etc., all the same stuff, the 36 seconds seem consistent, not a second more or less each boot.

 

disi ... not "dhcpcd", "net.eth0" ... 

 *disi wrote:*   

> Actual does Gnome3 use NetworkManager? Maybe I should start that daemon to the runlevel...

 

I have no idea, I don't use such things. It shouldn't be required, but then with Gnome who knows ... thats what comes of trying to remove the "user" from the equation.

best ... khay

----------

## disi

 *khayyam wrote:*   

>  *disi wrote:*   I added dhcpcd to the default runlevel etc., all the same stuff, the 36 seconds seem consistent, not a second more or less each boot. 
> 
> disi ... not "dhcpcd", "net.eth0" ... 

 

I cannot believe, we should still manually symlink net.lo to net.eth0 and add it to the runlevel?   :Rolling Eyes: 

Even then, all the dhcpcd timeout stuff etc. in /etc/conf.d/net and anywhere else seem to be ignored. The network part in openrc seems to be under constant change and not very well documented, sometime you have to use the arguments as arrays, sometimes not etc.

----------

## khayyam

 *disi wrote:*   

> I cannot believe, we should still manually symlink net.lo to net.eth0 and add it to the runlevel?

 

disi ... what is so "unbelievable", the fact that a "user" is involved in the process? I could think of any number of situations in which an automism, or huristic, will fail and where a "user" will be fair less likely to. Why? becuase users can think, whereas machines do not, they simply iterate rules. The logic of "usability" is the single most broken concept in computing, it is an abstraction that attempts to replace a "user" at the very nexus of which that concept makes sense: use.

As for "manually symlinking" see "Code Listing 2.9:" in the openrc migration guide

 *disi wrote:*   

> Even then, all the dhcpcd timeout stuff etc. in /etc/conf.d/net and anywhere else seem to be ignored. The network part in openrc seems to be under constant change and not very well documented, sometime you have to use the arguments as arrays, sometimes not etc.

 

Your conflating two or three (prehaps more) issues here ... firstly, dhcpcd doesn't consult /etc/conf.d/net, only net.${IFACE} does, so its no supprise that any configuration placed there is ignored. The issue is that the system provided method is at odds with the GnomeOS/freedesktop method, and there is some compromises made in order to incorporate the latter, namely to step aside and let the new-order have its way, but this compromise comes at a cost, the user is nolonger at the center of the system, they are a peripheral consideration ... and the complexity added makes understanding how the system works far more difficult, and hence if, and when, it goes wrong the user, having been removed from the equation, has little recourse than to accept their new role as peripheral observers.

Secondly, openrc is trying to incorporate two very different models of network configuration, one being user driven and the other being autoconfiguration, for the latter it simply hands over responcibility to other services, but from that point on its nolonger in control of what happens, and can't be re-awakened once that hand-off has occured. So, to accomodate the latter it has to give up its responcibility for management and, again, this comes at a price. Part of the "constant change" is related to this very issue (though I would say openrc is mostly consistant with prior methods, assuming it hasn't handed-off responcibility). 

Thirdly, bash arrays are from baselayout-1, they are legacy but will still work under the current system ... see: "Code Listing 2.10" in the openrc migration guide.

Fourthly, for most useage (and I mean openrc usage, not NetworkManager/wicd/etc usage) its sufficient to leave conf.d/net empty, for more specific configurations documentation is provided in the form of /usr/share/doc/openrc-{version}/net.example. This however only covers openrc, it doesn't cover every possible method of network configuration. If I were to criticise openrc I would say that services like wpa_supplicant, wicd, NetworkManager, dhcpcd, etc, should not be provided their own init.d/ script, as doing so adds to the confusion as to who, or what, is providing networking. But openrc is not simply for managing networking, all services are started by openrc, so such things can be provided by other services (the above mentioned "hand-off"). That said, I have no real issues with openrc .. but then I choose to use it in preference to the auto-configuration method.

best ... khay

----------

## disi

I suck and you Sir are my hero!

Finally I have control over my boot process again...   :Very Happy: 

The net.eth0 stuff did the trick, now I can set it to -t 5 seconds and do not have to wait over half a minute for the one daemon...

----------

## khayyam

disi ...

good ... and your "suckyness" only comes with trusting that some daemon is better than yourself at making decisions, when the inverse it true. Be your own hero! :)

I wonder, does the card now autonegociate correctly?

best ... khay

----------

