Bug 120427
Summary: | dhcp timeout should be 10 seconds by default | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Brian "netdragon" Bober <netdragon> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | barryn, floeff, rvokal |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-30 20:48:26 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Brian "netdragon" Bober
2004-04-08 18:24:12 UTC
I now can't figure out if that delay is caused by dhcp or what. The delays occur at the point where it goes: "Uniform CD-Rom Driver Revision" and "Updating /etc/fstab" in the graphical part. And happened one time when the ethernet cable was plugged in, but perhaps it still couldn't get an IP. I wish there were a better way to figure this out. Still, even though I can't figure it out ^.^ , you should probably know better than I if the timeout is ridiculously long still for dhcpcd. 5 seconds should be fine by default, and users should have an easy way to configure it system-wide and also be able to override it by interface. A setting of DHCP_TIMEOUT in the /etc/sysconfig/network-scripts/ifcfg-xxx files would probably be the best. It should be picked up each running of ifup. Or should it be done through /etc/dhclient.conf I created a file named /etc/dhclient.conf and put in "timeout 5;" and if I then change it to 50, running "/sbin/network restart" still appears to have a timeout of about 5. Yet, the changes do affect if I run /sbin/dhclient. Is that value even used? This is so frustrating, because I can't figure out exactly what's going on. That's why I have to ask if the 60 second timeout still occurs, since bug 64507 isn't marked fixed, and I now can't figure out if the DHCP timeout is actually occuring or not even though I thought it was at first. I wish figuring this stuff out were easier. Well.... There's a five second check for link before even starting dhclient... if there's no link, dhclient won't even get started. Aside from that, any timeouts with updfstab or the Uniform CD... are completely unrelated to dhclient... they happen way before it gets started. ok, bleh. I thought it was something else. I noticed /sbin/dhcpcd in the ifup script. Is that no longer used? i.e. is it never a possibility someone would end up using that instead? It seems in the ifup script that if /sbin/dhclient doesn't exist, it'll use /sbin/dhcpcd. If so, should dhcpcd have a timeout val to? If that's not an issue anymore (i.e. dhcpcd would never be used again), then maybe bug 64507 should be marked fixed since RH9.0 is no longer supported. Lets say there is a link, but no dhcp server (like if i just went an unplugged my switch right now from the firewall, would it then do the standard dhcp timeout? dhcpcd is for really old installs (it was shipped with 7.x.) In the case of link but no server, yes, it would do the standard timeout. > In the case of link but no server, yes, it would do the standard > timeout. Based on /etc/dhclient.conf? If so, should there be a value of "timeout 5"; in it? > dhcpcd is for really old installs (it was shipped with 7.x.) Is the dhcpcd stuff going to be removed from ifup? If you want a 5 second timeout, 'timeout 5' would be appropriate. You probably want longer, though. 30 seconds, maybe? dhcpcd stuff will get removed one of these days. I think 10 is all we need by default. If people want 30, they can modify the default setting in /etc/dhclient.conf. Right now, as tested, the default timeout is 60 seconds. I tested it by disconnecting the uplink to my switch. If you think 10 is too short, could we have at least a count-down appear to show how much time is left within the timeout period? Maybe that's a good idea anyway. For me, the update takes 4 seconds. [root@netdragon1 tmphw]# date; /sbin/dhclient -q; date Thu Apr 8 18:19:26 EDT 2004 /sbin/dhclient-script: configuration for sit0 not found. Thu Apr 8 18:19:30 EDT 2004 *** Bug 136944 has been marked as a duplicate of this bug. *** This bug looks sort of like bug 64507 to me; that bug is currently closed as WONTFIX. Also, a long timeout is needed for those of us who are stuck with flaky (but still usable) wireless connections. DHCP took about 33 seconds on the connection I'm using now. Look at my suggestion of interrupting DHCP, maybe with "Press Ctrl-C to override DHCP scanning" Barry: That bug was marked WONTFIX because of link check, which wasn't really a valid reason for marking it WONTFIX. If you read the former comments, link check doesn't solve a no dhcp server issue. You can be connected to a hub, but have no dhcp server, or have it down, and you are dead in the water. It's not necessary for the majority to wait 1 minute when a small minority has a flaky wireless connection. The majority shouldn't be punished. The setting can be modified in /etc/dhclient.conf Closing bugs on older, no longer supported, releases. Apologies for any lack of response. Realistically, most of this code is going to be replaced in the future by NetworkManager support; as such, I don't expect to be changing the default timeouts. It is a locally modifyable config setting for those who need it, though. |