# Network too slow to set up



## mururoa (Aug 22, 2010)

Hi,
This is a problem I kinda had when upgrading from 7.3 to 8.0. In 7.3 I was in dhcp and I 'solved' it by setting fixed IP @.
The problem is that the network is too slow to setup and this cause an error and I'm dropped to the shell to fix. When I get the shell I just do ^D and the boot continues.
I mean that if I use some kind of network service in the boot process it wont work and so it interrupt the boot since the network is not available when the service request it.
For example ntpdate or mounting network filesystems.
I upgraded all to 8.1 release and my network driver is ale.
Doh I just thought I didnt tried to fix network speed


----------



## mururoa (Aug 22, 2010)

Grrr nothing changed 

So my boot process is :
- start computer
- wait network mount error
- press enter to get shell and immediately ^D to continue boot

In the end the network filesystem is mounted and all is OK outside that.
The network filesystem is an USB stick connected to my router :


```
//guest@ROUTEUR/nas     /shares/stick   smbfs   rw,late,-N       0       0
```


----------



## wblock@ (Aug 22, 2010)

Use SYNCDHCP so the boot waits until it gets a lease:

```
ifconfig_ale0="SYNCDHCP"
```


----------



## mururoa (Aug 22, 2010)

Hey great it works like that, thanks 
... but it seems more like a workaround. What would cause the network to be so slow to be ok ? A known ale driver issue ?
Anyway I'll keep it like that. DHCP is better for my use than fixed @.


----------



## wblock@ (Aug 22, 2010)

Running dhclient in the background is a relatively recent change.  If there are non-network services starting, running dhclient in the background can speed up booting.  SYNCDHCP runs it in the foreground, so the boot doesn't continue until dhclient gets a lease or gives up.


----------



## phoenix (Aug 22, 2010)

It's not a "workaround" it's a fix for the root cause of the issue.  

In a "normal" boot, dhclient is run in the background so that other local daemons can load while the kernel waits for a DHCP lease.  Hopefully, it gets a lease before any network services need to start.

However, if you find that your system is booting to the point where it's trying to start network services before a DHCP lease has been received, then you switch to "synchronous dhcp", which runs dhclient in the foreground and pauses the boot process until it get an IP or fails.

IOW, which you use depends on your environment.


----------



## mururoa (Aug 23, 2010)

@phoenix : I still consider this as a workaround since the system should start normally in fixed address mode. I mean it's a fix for the use of dhcp but I should not be forced to use dhcp, even it it's better for my usage. What if I have no dhcp server @ home ?


----------



## wblock@ (Aug 23, 2010)

mururoa said:
			
		

> @phoenix : I still consider this as a workaround since the system should start normally in fixed address mode. I mean it's a fix for the use of dhcp but I should not be forced to use dhcp, even it it's better for my usage. What if I have no dhcp server @ home ?



You're not forced to use DHCP.  If you set a static IP address in /etc/rc.conf, there is no dhclient , so no timing problem.


----------



## mururoa (Aug 24, 2010)

wblock said:
			
		

> You're not forced to use DHCP.  If you set a static IP address in /etc/rc.conf, there is no dhclient , so no timing problem.



Read first post. I was in static IP and I had the problem. Only SYNCDHCP kinda solved my problem so far.


----------



## wblock@ (Aug 24, 2010)

mururoa said:
			
		

> Read first post. I was in static IP and I had the problem. Only SYNCDHCP kinda solved my problem so far.



Your first post says you "solved it" by using a static IP.  However, it gives no details, and maybe I'm reading it wrong.  Please elaborate.


----------



## mururoa (Aug 25, 2010)

wblock said:
			
		

> Your first post says you "solved it" by using a static IP.  However, it gives no details, and maybe I'm reading it wrong.  Please elaborate.



First post says I solved dhcp problem when upgrading from 7.3 to 8.0 by using static IP and the problem comes back in 8.1 with static IP and was later 'fixed' with your help coming back to dhcp and syncdhcp.

7.3 dhcp ok
8.0 dhcp problem. Using static IP.
8.1 static IP problem. Using dhcp with syncdhcp.

I assume 8.0 dhcp problem is coming from not using syncdhcp but the question that remains is : why cant I use static IP with 8.1 ?
Of course my problem is solved with syncdhcp but I would be happy to understand the problem with static IP.


----------



## wblock@ (Aug 25, 2010)

A better description would be "why isn't a static-IP ale0 ready in time for a smbfs mounted in mountlate?"

Maybe just a timing difference in 8.x, like ale0 taking a few seconds to initialize.  One way to fix that would be to make the smbfs mount noauto, and then mount it later from a user script in /usr/local/etc/rc.d/.

A better way would be to modify /etc/rc.d/mountlate to be smarter about network file systems, like mountcritremote.


----------



## mururoa (Aug 25, 2010)

Kinda yes but this is not only about mountlate since any network service will fail too like ntpdate.


----------



## nomad (Apr 29, 2011)

I'm having the same problem on my newly created FreeBSD 8.2-STABLE box - NFS exports, ntpd, etc all fail because they try to start before bge0 is fully configured.  I am using a static address set in /etc/rc.conf and dhcp (thus syncdhcp) isn't an option for this server.  Are there any plans to create an rc.conf setting we can use to say "wait until the network is up before calling any other network scripts"?  Perhaps the defaultroute_delay flag could be changed to effect all network statup, not just dhcp? 

Please?

nomad


----------



## phoenix (Apr 30, 2011)

Yes, it's coming in 9.0, and there are patches floating around for it on the mailing lists.

Search for Jeremy Chadwick's posts on /etc/rc.d/defaultroute on the -stable and -current mailing lists.

Basically, you give it an IP to connect to, and it will pause the boot process until that IP is reachable, meaning the network is up and configured.


----------



## nomad (May 2, 2011)

Thank you, PR 151063 was exactly what I was looking for.  I have no idea why my earlier Googling for it didn't find it, all the right keywords were there.


----------



## mamalos (May 11, 2011)

Another workaround regarding *remote mounts* is to use *amd*, if I've understood the problem correctly. This way, the system boots normally, since no remote mounts are located in /etc/fstab, and remote filesystems get mounted the first time the user wishes to access them. But *this* is indeed a workaround .


----------



## nomad (May 11, 2011)

mamalos,  I use amd quite heavily.  The problem is this is a file server, not a client.  The exports were failing because the hosts weren't known when mountd went to look (since DNS wasn't working since the network wasn't working...).  The delay-until-ping solution solved this problem for me.


----------

