Re: dhcp-client cleanup
- From: cga <cga2001@xxxxxxxxx>
- Date: Sun, 26 Feb 2006 16:38:41 -0500
Bit Twister wrote:
[...]
Hmmm, you could be right, but here is a snippet from my distro's man page
The client normally doesn't release the current lease as it is not
required by the DHCP protocol. Some cable ISPs require their clients
to notify the server if they wish to release an assigned IP address.
The -r flag explicitly releases the current lease, and once the lease
has been released, the client exits.
no trace of this in the man page that came with mine.
and no -r flag either:
# dhclient --help
Internet Software Consortium DHCP Client
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.
Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html
Usage: dhclient [-c] [-d] [-e] [-p <port>] [-lf lease-file]
[-pf pidfile] [interface]
exiting.
no indication of a version or anything.. even a cursory glance at the output of "strings $(which dhclient)" did not provide a clue as to what this thing is..
mind you this is the version that *works* .. the sarge one.. so the one in etch might be more recent and have the -r flag..
Once you get a lease, your box is supposed to renew it based on renew,
rebind, expire times in the dhclient*.leases file.
ok. so if I understand you correctly I should edit this file
Never suggested that
nothing personal.. I've been stuck with this problem for three weeks now and I am extremely grateful you offered your help.. I was referring to what I see as failings/limitations of the dhclient program..
well.. from what I have seen once dhclient has done its initial dance - at startup eg. or when you run it from a shell.. it puts itself in the background.. so you may be able to sigusr it.. or jus kill it and restart it..
- changing the rebind or expiration date and wait for dhclient to
wake up and take action..?
I would guess those values are stored in memory before writing them to
the leases file. Changing them will not get the client's attention
until next boot.
meaning the lease only gets written to disk after you shut down the system..?
now the problem with this is that on the etch system the
dhclient.eth0.leases file is created empty - since I was unable to
obtain a lease -
That is normaly a day one condition and would expect that.
agreed .. I think it also has something about using it to provide a fixed address for when no dhcp server is not available.. mobile users who might connect to a different LAN occasionally..
So, should I create a syntactically valid file with a fake ip address etc. and an expiration date/time at eg. current time plus thirty seconds.. save it.. and wait for dhclient to wake up and seeing that the lease is expired go get me a new one..???
Off hand, I would say no. From man page
Old leases are kept around in case the DHCP server is unavailable when
dhclient is first invoked (generally during the initial system boot
process). In that event, old leases from the dhclient.leases file
which have not yet expired are tested, and if they are determined to be
valid, they are used until either they expire or the DHCP server
becomes available.
[...]
yes.. or more of a timing issue.. networking is started too early and does something that makes further manual attempts fail.. maybe this only happens because of the way my ISP have set up dhcp.. and that's why having really no time to debug this seriously I was trying to figure out if there might be some way I could "start afresh"..
It would seem, you could release the ip lease under win98, boot etch toI tried that but it did not work.. that's why I was thinking that something happens when I start etch that partly initializes the connection process.. fails.. and leaves me in a "funny" state where further attempts to bring up the connection manually just fail..otoh as I mentioned earlier.. if I wait long enough it would seem that I am all of a sudden able to bring up the connection.. my guess being that the dhcp server at the other end eventually detects that I am not connected and does some cleanup.. have not evidence this is the case, though.. just a hunch..
rule out dhcp server interaction about assigned IP address.
no.. my objective was not to debug a faulty debian setup.. just finding a quick workaround if anybody could suggest one..and unfortunately I neither have the time
Which indicates we should not be wasting our time with it either.
nor the ability to debug this.
If it is script knowledge, these will help.
! bash script introduction documentation
http://tldp.org/LDP/intro-linux/html/index.html
! bash script advanced documentation
http://tldp.org/LDP/abs/html/index.html
more likely I would need to use tcdump and trace the dhcp conversation to sse what is really going on..
Thanks much for help.
.
- Follow-Ups:
- Re: dhcp-client cleanup
- From: Bit Twister
- Re: dhcp-client cleanup
- References:
- dhcp-client cleanup
- From: cga
- Re: dhcp-client cleanup
- From: Bit Twister
- Re: dhcp-client cleanup
- From: cga
- Re: dhcp-client cleanup
- From: Bit Twister
- Re: dhcp-client cleanup
- From: cga
- Re: dhcp-client cleanup
- From: Bit Twister
- dhcp-client cleanup
- Prev by Date: Re: Fedora Core 4 Networking: Ping DNS problem
- Next by Date: Linux Shoutcast/Icecast Source.
- Previous by thread: Re: dhcp-client cleanup
- Next by thread: Re: dhcp-client cleanup
- Index(es):
Relevant Pages
|