On Mon, 22 Jun 2009, Seewer Philippe wrote:
DHCP timeout already is 60 seconds. That's dhclient's default if you don't provide other options.
On a network where I don't have control over the switch (some Cisco model) and people connect laptops, I've seen random cases of DHCP failing. That's because the STP can take 60 seconds and DHCP gives up just when the link becomes usable... For the workstations connected on another network where STP is also enabled, I've experimented with various solutions, the one using ping to the gateway (with a timeout of 100 seconds) worked best and was simplest for me to maintain.
The problem only manifests itself it we have to correct the mtu after dhcp, which currently set's the interface down and up (paranoia I guess), or if we do static configuration.
No, it's not paranoia. Maybe things have changed in the meantime, but some years ago when I was involved in the Linux network stack some drivers couldn't change the MTU on the fly due to internal limitations. The only possibility to change it would be to bring the interface down then up. Not all drivers are limited this way, though. Maybe it's possible to try to set the MTU, check whether it has succeeded and only if it failed bring the interface down then up; don't know anymore if a failed MTU setting would make ifconfig return something... maybe just reading the MTU again and compare with desired would work too.
-- Bogdan Costescu IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany Phone: +49 6221 54 8240, Fax: +49 6221 54 8850 E-mail: bogdan.costescu@xxxxxxxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
