Re: dhcp-client cleanup


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?

.

Relevant Pages

  • Re: IP Address Problems
    ... Ok, that change is easy enough to make, but why isn't it honoring the DHCP lease time from my DHCP server? ...
    (Ubuntu)
  • Re: Problems with DHCP (I believe)
    ... >>>says I have just gotten a new lease. ... >>>DHCP Server ... >>all ICMP will also cause you trouble. ... >>but it cann't communicate with the ISP DHCP server. ...
    (comp.security.firewalls)
  • Re: Problems with DHCP (I believe)
    ... >>>says I have just gotten a new lease. ... >>>DHCP Server ... >>all ICMP will also cause you trouble. ... >>but it cann't communicate with the ISP DHCP server. ...
    (comp.security.firewalls)
  • Re: DHCP
    ... connected to a DHCP server with a 40 minute lease time. ... > I have a client system with say Ipaddress 10.0.0.25. ...
    (microsoft.public.windows.server.networking)
  • Re: dhcp-client cleanup
    ... it would be sad if a client could reset a server. ... 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. ... I've even tried copying over the lease file from the sarge /var/run/ but that did not work either. ...
    (comp.os.linux.networking)