Bug 64507 is about a dhcp timeout and got lost somewhere back there
and has apparently been abandoned.
The issue was a dhcp timeout causing the computer to seem to lock up
because dhcp has too large of a timeout period.
This is even worse in Fedora Core 2 test 2 because now you don't even
know its trying to do a dhcp check, it appears to freeze up in two
places, one is when it says "Uniform CD-Rom driver Revision x.xx" amd
another is when its doing the new graphical boot screen.
Although I have a router, I tested it by unplugging the cable. All we
need is a -t argument sent to dhcp.
I offered a solution in that bug, adding something like DHCP_TIMEOUT
to /etc/sysconfig/network by default. I think that'd be good because
then people could change the number and they'd see its there.
I think its also necessary to let people know why the computer is
stalling with some message like: "Doing a dhcp request, this could
take $DHCP_TIMEOUT seconds".
I am filing this bug because I can no longer comment in the bug 64507:
"You tried to change the component field from AfterStep-APPS to
initscripts, but only the owner or submitter of the bug, or a
sufficiently empowered user, may change that field."
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"
"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.
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
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
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
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
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.