dhcp-client cleanup

How can I use dhclient (or another tool) to force the expiration/renewal
of my current dhcp lease..? Windows 98' provides this functionality via
winipcfg but I could not find anything similar mentioned in the dhclient
man page. The objective is to start afresh from a "clean" environment.

On Sat, 25 Feb 2006 19:39:58 -0500, cga wrote:
> How can I use dhclient (or another tool) to force the expiration/renewal
> of my current dhcp lease..? Windows 98' provides this functionality via
> winipcfg but I could not find anything similar mentioned in the dhclient
> man page. The objective is to start afresh from a "clean" environment.

You could just delete the dhclient*.leases file, and restart the
network. For me it would be
rm /var/lib/dhcp/dhclient-eth1.leases
service network restart

Of course it might depend on what distribution you are running on.

Bit Twister wrote:
> On Sat, 25 Feb 2006 19:39:58 -0500, cga wrote:
>
>>How can I use dhclient (or another tool) to force the expiration/renewal
>>of my current dhcp lease..? Windows 98' provides this functionality via
>>winipcfg but I could not find anything similar mentioned in the dhclient
>>man page. The objective is to start afresh from a "clean" environment.
>
>
> You could just delete the dhclient*.leases file, and restart the
> network. For me it would be
> rm /var/lib/dhcp/dhclient-eth1.leases
> service network restart

hmm.. that would reset the client system to its original state but the
dhcp server system.. depending on how it is configured would still
retain the lease information.. and might refuse to give me another lease
because it thinks I already have one (?) And since I have no access to
my ISP's dhcp server configuration I cannot verify the above assumption.

>
> Of course it might depend on what distribution you are running on.

Debian sarge and etch. The sarge system has never had any problems
connecting. The etch system, otoh, practically never connects
successfully.. Except that the other day I left it up overnight.. ran
dhclient manually in the morning and immediately obtained a lease.. eth0
and the route table were correctly configured and I was able to go
online. So my guess since I had changed nothing in my setup is that for
some reason my isp's dhcp server having heard nothing from me for a
number of hours decided to reclaim my lease.

This is all guesswork as I have really no knowledge of dhcp.. but I
would imagine that the server would keep track of which machines/nic's
he has already provided with and ip address and might would turn down a
new request from a machine with a currently active lease..

And that would explain why I am practically never able to bring up the
connection.

Does this make any sense..?

On Sat, 25 Feb 2006 21:47:11 -0500, cga wrote:
>
> hmm.. that would reset the client system to its original state but the
> dhcp server system..

Yep, it would be sad if a client could reset a server.

> depending on how it is configured would still
> retain the lease information.. and might refuse to give me another lease
> because it thinks I already have one (?) And since I have no access to
> my ISP's dhcp server configuration I cannot verify the above assumption.

Well, a new requirement.
Doing a
man dhclient
would suggest you could release the assigned ip addy.


>
> Debian sarge and etch. The sarge system has never had any problems
> connecting. The etch system, otoh, practically never connects
> successfully.. Except that the other day I left it up overnight.. ran
> dhclient manually in the morning and immediately obtained a lease.. eth0
> and the route table were correctly configured and I was able to go
> online. So my guess since I had changed nothing in my setup is that for
> some reason my isp's dhcp server having heard nothing from me for a
> number of hours decided to reclaim my lease.

Once you get a lease, your box is supposed to renew it based on renew,
rebind, expire times in the dhclient*.leases file.


> This is all guesswork as I have really no knowledge of dhcp.. but I
> would imagine that the server would keep track of which machines/nic's
> he has already provided with and ip address and might would turn down a
> new request from a machine with a currently active lease..

I have no direct knowledge about a server, but, I know I get the same
IP address from my ISP, regardless if I released the IP address or not.

> And that would explain why I am practically never able to bring up the
> connection.

Only if your log show the request refused.

Are the errors, dropped, overruns, frame faults pretty clean
ifconfig

For extra points
http://www.ietf.org/rfc/rfc2131.txt

Bit Twister wrote:
> On Sat, 25 Feb 2006 21:47:11 -0500, cga wrote:
>
>>hmm.. that would reset the client system to its original state but the
>>dhcp server system..
>
>
> Yep, it would be sad if a client could reset a server.
>
otoh wouldn't it make sense being able to tell the server.. ok I'll be
on the road with this machine for the next couple of days so I won't be
needing this ip address.. feel free to move it back to your pool of
free/unused ip addresses.. Or am I missing something..?

>
>> depending on how it is configured would still
>>retain the lease information.. and might refuse to give me another lease
>>because it thinks I already have one (?) And since I have no access to
>>my ISP's dhcp server configuration I cannot verify the above assumption.
>
>
> Well, a new requirement.
> Doing a
> man dhclient
> would suggest you could release the assigned ip addy.
>

at least on my system - the dhclient man page only talks of configuring
one (or several) interface(s).. says nothing about de-configuring them
or releasing the ip address.. doesn't say anything about turning on some
form of verbose/debugging mode either :-(

>
>
>>Debian sarge and etch. The sarge system has never had any problems
>>connecting. The etch system, otoh, practically never connects
>>successfully.. Except that the other day I left it up overnight.. ran
>>dhclient manually in the morning and immediately obtained a lease.. eth0
>>and the route table were correctly configured and I was able to go
>>online. So my guess since I had changed nothing in my setup is that for
>>some reason my isp's dhcp server having heard nothing from me for a
>>number of hours decided to reclaim my lease.
>
>
> 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 - changing
the rebind or expiration date and wait for dhclient to wake up and take
action..?

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 - 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..???

Apart from striking me as being rather complicated .. I'm not sure this
would work anyway.. since surely the dhcp server at the other end must
keep track of the leases it has served - with rebind.. expiration dates
and times.. etc.

I've even tried copying over the lease file from the sarge /var/run/ but
that did not work either. IIRC dhclient could not get a lease from the
server.. fell back on the lease that was in the lease file.. ifconfig
eth0 showed the ip address dhclient picked up from the lease file.. but
the interface was not listed as "up" and the routing table was not
configured.

>
>>This is all guesswork as I have really no knowledge of dhcp.. but I
>>would imagine that the server would keep track of which machines/nic's
>>he has already provided with and ip address and might would turn down a
>>new request from a machine with a currently active lease..
>
>
> I have no direct knowledge about a server, but, I know I get the same
> IP address from my ISP, regardless if I released the IP address or not.
>
>
>>And that would explain why I am practically never able to bring up the
>>connection.
>
>
> Only if your log show the request refused.

Nothing of the sort.. It just sends out its requests and fails to obtain
a lease practically every time - got a connection twice in possibly a
hundred attempts over a period of three weeks.

With the same identical hardware and the same ISP, I always connect
whenever I bring up the sarge system.

Maybe I should try removing everything that has to do with bringing up
the network from /etc/rc.2 and try to do everything manually since I am
pretty sure that the problem is with the etch init scripts. I tried a
number of debian-derived live CD's and ran into the same problem every
time. otoh I tried the current version of the "linux system rescue CD"
which is based on gentoo and eth0 came up every time.

>
> Are the errors, dropped, overruns, frame faults pretty clean
> ifconfig

Well I didn't look since I was unable to bring up eth0 I didn't think
there would be anything there of any significance.

> s
> For extra points
> http://www.ietf.org/rfc/rfc2131.txt

Maybe I should email it to my ISP..? :-)

No.. I have three different systems installed on this laptop Win98..
sarge.. and etch.. and only etch has this connection problem. So either
way I look at it the odds are that the etch networking scripts are the
culprit.. and unfortunately I neither have the time nor the ability to
debug this.

On Sun, 26 Feb 2006 01:42:10 -0500, cga wrote:

> otoh wouldn't it make sense being able to tell the server.. ok I'll be
> on the road with this machine for the next couple of days so I won't be
> needing this ip address.. feel free to move it back to your pool of
> free/unused ip addresses..

You can do it to be polite.

> Or am I missing something..?

But the ip address will be released when it expires.


>>> depending on how it is configured would still
>>>retain the lease information.. and might refuse to give me another lease
>>>because it thinks I already have one (?) And since I have no access to
>>>my ISP's dhcp server configuration I cannot verify the above assumption.
>>
>>
>> Well, a new requirement.
>> Doing a
>> man dhclient
>> would suggest you could release the assigned ip addy.
>>
>
> at least on my system - the dhclient man page only talks of configuring
> one (or several) interface(s).. says nothing about de-configuring them
> or releasing the ip address..

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.

>> 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

> - 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.

> 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.

> 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.


> Apart from striking me as being rather complicated .. I'm not sure this
> would work anyway.. since surely the dhcp server at the other end must
> keep track of the leases it has served - with rebind.. expiration dates
> and times.. etc.

Not to mention, using the nic's MAC in concert with assigned IP


> I've even tried copying over the lease file from the sarge /var/run/ but
> that did not work either. IIRC dhclient could not get a lease from the
> server.. fell back on the lease that was in the lease file.. ifconfig
> eth0 showed the ip address dhclient picked up from the lease file.. but
> the interface was not listed as "up" and the routing table was not
> configured.

That I can believe. dhcp script tells the ifup script it failed and
ifup does not try to continue with setup.


> Maybe I should try removing everything that has to do with bringing up
> the network from /etc/rc.2

I run Mandriva Linux so I would have to run at level 3 for network on boot.

> and try to do everything manually since I am
> pretty sure that the problem is with the etch init scripts.

That is pretty bold thinking.
If you can bring up the connection manualy, then you should be able to
debug the scripts without removing them from the rc directories.


> No.. I have three different systems installed on this laptop Win98..
> sarge.. and etch.. and only etch has this connection problem.

Now that you provided some facts/debugging information, that rules out
other possible problems.

> So either way I look at it the odds are that the etch networking
> scripts are the culprit..

Since you indicate they work sometimes that would indicate a race condition.

It would seem, you could release the ip lease under win98, boot etch to
rule out dhcp server interaction about assigned IP address.

> 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

cga wrote:
> Bit Twister wrote:
> > On Sat, 25 Feb 2006 21:47:11 -0500, cga wrote:
[snip]

> otoh wouldn't it make sense being able to tell the server.. ok I'll be
> on the road with this machine for the next couple of days so I won't be
> needing this ip address.. feel free to move it back to your pool of
> free/unused ip addresses.. Or am I missing something..?

BT has already mentioned dhclient -r. Your lease likely expires in 24
hours (just a common practice), the ISP likely doesn't care if you're
gone for several days as they may not give out the IP to anyone else
(in fact, your lease may be for a fixed address anyway), and if they
want it back to use it elsewhere they will configure their end to do
that without your help, thank you.

The note in dhclient's man page is not as relavant today (in the US) as
it once was. Most ISP's maintain sufficient address space for all
their clients (ie., are not oversubscribed) and their
accounting/monitoring systems are easier to maintain with fixed or
relatively stable address assignments.

> >> depending on how it is configured would still
> >>retain the lease information.. and might refuse to give me another lease
> >>because it thinks I already have one (?) And since I have no access to
> >>my ISP's dhcp server configuration I cannot verify the above assumption.

You can ask for renewal at any time and the dhcp server will (should)
be happy as a clam to do what it needs to do. In fact, automatic
renewals begin occuring at 1/2 way into the lease, and will continue at
succeding periods according to a "formula" right up to expiry or until
a renewal is acquired. You don't have to do anything to "help" the
server maintain its address assignments.

[snip]

> >>Debian sarge and etch. The sarge system has never had any problems
> >>connecting. The etch system, otoh, practically never connects
> >>successfully.. Except that the other day I left it up overnight.. ran
> >>dhclient manually in the morning and immediately obtained a lease.. eth0
> >>and the route table were correctly configured and I was able to go
> >>online. So my guess since I had changed nothing in my setup is that for
> >>some reason my isp's dhcp server having heard nothing from me for a
> >>number of hours decided to reclaim my lease.

Either your lease expired without a renewal request filled (unlikely
without screwed up networking scripts) or you did indeed "lose" your
connection due to inactivity. The latter is quite common with ADSL
connections as the phone company does not like wasting _its_ resouces
by maintaining a connection circuit for a silent client (just like your
telephone not going onhook after the other end is closed). It has the
added advantage of discouraging clients operating "unattended" network
servers (eg., web or FTP) without paying for "business class" service.

> > 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 - changing
> the rebind or expiration date and wait for dhclient to wake up and take
> action..?

DO NOT edit this file. It tells your system how to play nicely with
the server. The _server_ wrote the file for that purpose. While it is
_possible_ to formulate a request contrary to what the server expects,
don't expect it to blindly follow your orders unless you contol the
server configuration. Servers are funny that way.

> 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 - 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..???

No lease, no new file entry. Never got a lease, an empty file. No
active network either. You can try manually to acquire a lease with #
ifup eth0 or whatever script/mechanism etch provides. Likewise you can
# ifdown eth0 to disonnect. Look at your script(s) to see if dhclient
"releases" or not when ifdown is called.

> Apart from striking me as being rather complicated .. I'm not sure this
> would work anyway.. since surely the dhcp server at the other end must
> keep track of the leases it has served - with rebind.. expiration dates
> and times.. etc.

The networking scripts _can_ be complicated and dhcp may seem
complicated at first. The RFCs are not too difficult to understand.
Try these for the gory details:
http://www.faqs.org/rfcs/rfc2131.html
http://www.faqs.org/rfcs/rfc2132.html

> I've even tried copying over the lease file from the sarge /var/run/ but
> that did not work either. IIRC dhclient could not get a lease from the
> server.. fell back on the lease that was in the lease file.. ifconfig
> eth0 showed the ip address dhclient picked up from the lease file.. but
> the interface was not listed as "up" and the routing table was not
> configured.

It did precisely what it was supposed to do the way it was supposed to
do it :-)

Not sure what you mean by "did not work either" but presume that you
mean that etch still did not get a lease or bring up the network.

> >>This is all guesswork as I have really no knowledge of dhcp..

Advise you get you some dhcp mojo, then, before you start aimlessly
changing things brought on by a hunch.

> >> ... but I
> >>would imagine that the server would keep track of which machines/nic's
> >>he has already provided with and ip address and might would turn down a
> >>new request from a machine with a currently active lease..

Sounds like your etch setup is faulty. The dhcp server does not know
which OS is requesting a lease (except for Win), does not ultimately
care when/if it gets a renewal request, or new lease request (after
expiry), or never hears from you again.

> > I have no direct knowledge about a server, but, I know I get the same
> > IP address from my ISP, regardless if I released the IP address or not.
> >
> >>And that would explain why I am practically never able to bring up the
> >>connection.

This has _nothing_ to do with why you don't get a connection (most
likely). You can look at the sarge dhclient-leases file for clues as
to how the server operates. Compare that with any info you have/get
about etch's start up scripts. In the end, a packet capture with
ethereal will reveal the _exact_ nature of the dhcp exchange and tell
you _exactly_ how the server is behaving and _may_ provide clues why
etch is having problems aquireing a lease.

> > Only if your log show the request refused.
>
> Nothing of the sort.. It just sends out its requests and fails to obtain
> a lease practically every time - got a connection twice in possibly a
> hundred attempts over a period of three weeks.

Then get out ethereal and look at the dhcp exchange with sarge as well
as etch. Compare their respective dhclient.conf files for differences
also. How is the etch request different from the sarge request? This
difference is ultimately the nature of your problem. Check that the
client-ID is presented the same way in both sarge and etch.

There _is_ a possibility that your ISP is running a wimpy, easily
confused dhcp server configuration. Most likely culprit is that it is
getting confused or onery because the same mac address is requesting a
lease in a manner that the server does not like. BTW, the dhclient
note re: cable cos _may_ be relevant. If so then you _may_ need to add
a release notification in _both_ sarge and etch scripts (if it's not
there already).

The fact that Win98 is not boinking anything makes it sound like the
server can handle different request styles. Does Win98 get the same IP
as sarge?

> With the same identical hardware and the same ISP, I always connect
> whenever I bring up the sarge system.
>
> Maybe I should try removing everything that has to do with bringing up
> the network from /etc/rc.2 and try to do everything manually since I am
> pretty sure that the problem is with the etch init scripts.

VERY highly _not_ recommended approach.

> ... I tried a
> number of debian-derived live CD's and ran into the same problem every
> time. otoh I tried the current version of the "linux system rescue CD"
> which is based on gentoo and eth0 came up every time.

>From what I've read, many live-cd distros have less than robust
networking scripts. And network startup is easy to get "wrong" because
the infinite variety of hardware, software and configuration
environments.

[snip]

> No.. I have three different systems installed on this laptop Win98..
> sarge.. and etch.. and only etch has this connection problem. So either
> way I look at it the odds are that the etch networking scripts are the
> culprit.. and unfortunately I neither have the time nor the ability to
> debug this.

Then don't mess with any dhclient.conf or leases files or anything else
that may effect your _working_ OSes or the dhcp server's view of your
system. It likely is a "script" issue but where in the script(s) the
problem arises can be difficult to locate. Sometimes an ethereal
capture will show an obvious difference in the manner of the dhcp
requests which can be readily fixed with a ''corrected" configuration,
but often it requires some digging just to get the relavant clue.
Without time to chase down problems, and with so many distros out
there, I would just move on to another one.

OTOH, getting etch to work will probably teach you a great deal about
how networks are brought up with DHCP which may serve you well in a
future snafu ;-)

good luck,
prg

PS I assume that you have confirmed that etch is able to properly load
your required nic driver. What can you learn with ifconfig, mii-tool,
or ethtool?

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..
>
>
>>- 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.
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..
>
>
>>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.
>
meaning the lease only gets written to disk after you shut down the
system..?
>
>>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.
>
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..
>

[...]

>
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 to
> rule out dhcp server interaction about assigned IP address.
>
>
I 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..

>>and unfortunately I neither have the time
>
>
> Which indicates we should not be wasting our time with it either.
>
no.. my objective was not to debug a faulty debian setup.. just finding
a quick workaround if anybody could suggest one..

>
>>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.

On Sun, 26 Feb 2006 16:38:41 -0500, cga wrote:
>
> # dhclient --help
> Internet Software Consortium DHCP Client
> Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
> All rights reserved.


Well there you are, you need a new and improved client.

$ dhclient --help
Internet Systems Consortium DHCP Client V3.0.3
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Usage: dhclient [-1dqr] [-nw] [-p <port>] [-s server]
[-cf config-file] [-lf lease-file][-pf pid-file] [-e VAR=val]
[-sf script-file] [interface]


>>
>> That is normaly a day one condition and would expect that.
>>
> meaning the lease only gets written to disk after you shut down the
> system..?

No, when the client gets it's first lease.


> ... or more of a timing issue.. networking is started too early and
> does something that makes further manual attempts fail..

I know with an old release of my software and a slow dhcp server, I
would miss a lease. I created a network_ck script to ping the gateway
and if failed, re-run the network script and would get a lease.


>
>> It would seem, you could release the ip lease under win98, boot etch to
>> rule out dhcp server interaction about assigned IP address.
>>
>>
> I 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..

I understand, but, you started out wanting to have the server reset.
We showed the problem did not clear up when you released the ip addy
with windows.
Since you are using the same hardware, you should have received a lease.

I would get a new and improved dhclinet before doing anything else.
You still maybe stuck with reading dhcp packets.

Bit Twister wrote:
> On Sun, 26 Feb 2006 16:38:41 -0500, cga wrote:
>
>># dhclient --help
>>Internet Software Consortium DHCP Client
>>Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
>>All rights reserved.
>
>
>
> Well there you are, you need a new and improved client.
>
> $ dhclient --help
> Internet Systems Consortium DHCP Client V3.0.3
> Copyright 2004-2005 Internet Systems Consortium.
> All rights reserved.
> For info, please visit http://www.isc.org/products/DHCP
> Usage: dhclient [-1dqr] [-nw] [-p <port>] [-s server]
> [-cf config-file] [-lf lease-file][-pf pid-file] [-e VAR=val]
> [-sf script-file] [interface]
>
He he.. the problem here is that this older version is the one I have in
sarge .. the system that never had a problem connecting.. But this is a
useful lead. I don't know for sure what version etch installed but on
sarge there is a dh3client package available - which I did not install -
and that should be more or less the one you're running..

>
>
>>>That is normaly a day one condition and would expect that.
>>>
>>
>>meaning the lease only gets written to disk after you shut down the
>>system..?
>
>
> No, when the client gets it's first lease.
>
>
>
>>... or more of a timing issue.. networking is started too early and
>>does something that makes further manual attempts fail..
>
>
> I know with an old release of my software and a slow dhcp server, I
> would miss a lease. I created a network_ck script to ping the gateway
> and if failed, re-run the network script and would get a lease.
>
marginally possible.. I never thought of running ifup in a loop to check
whether I would eventually obtain a lease after a few dozen attempts.

>
>
>>>It would seem, you could release the ip lease under win98, boot etch to
>>>rule out dhcp server interaction about assigned IP address.
>>>
>>>
>>
>>I 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..
>
>
> I understand, but, you started out wanting to have the server reset.

Well not reset the server .. just be able to tell it to clean up
everything that concerns me. The problem I am trying to work around is
the fact that my ISP only support Windows PC's and MAC's.. So I can't
just pick up the phone .. complain that I am unable to obtain a lease
reliably and ask them to look into it.. Since I do not have access to
their dhcp setup I'm pretty much stuck with the guessing game approach
... unless I choose to spend countless hours tracing the actual dhcp
packets and - perhaps - eventually figuring out what's going on.

> We showed the problem did not clear up when you released the ip addy
> with windows.

my impression is that whatever etch does at bootup fails but does not
leave me with a clean slate. If I boot into windows.. release the lease
and then boot into sarge.. I am connected with a new lease.. never
fails.. if I do the same thing with the etch system it always fails at
bootup and ensuing attempts to bring up my connection manually are
almost always unsucessful.. So my impression is that it not only fails
but whatever it does messes up things so that I am unable to connect
manually thereafter..

> Since you are using the same hardware, you should have received a lease.
>

etch installs a 2.6.12 kernel by default - that's the reason I installed
it in the first place.. I needed a recent 2.6 kernel for a totally
different reason - and these new kernels use that new udev, hotplug,
devfs stuff so even though the hardware is the same, the software that
handles it has undergone drastic changes.. and my feeling is that - at
least where I and my ISP are concerned - the debian scripts that handle
the connection at startup do no do the right thing.. That's why I
thought I could try disabling them.. realeasing the lease.. and then
running ifup manually might be successful and that could give me some
understanding of what's going on.

> I would get a new and improved dhclinet

I suppose I could download the v3 version of the dhclient package using
my sarge connection and install it on the etch system.. likely to be
messy since the dh3client might have dependencies and I might have to
upgrade/install a bunch of other things..

before doing anything else.
> You still maybe stuck with reading dhcp packets.

I would hate to have to do that without being able to see how they are
configured at the other end.. After all while my ISP are doing some form
of dhcp I would not be surprised if they had tweaked it one way or
another to suit their "business needs" .. wouldn't be the first time a
commercial entity add their own "enhancements" to the standard as
described in the rfc's.

I'm beginning to think that it might be easier to install sarge on a
gateway machine and connect the laptop to it ;-)

Thanks.