Re: dhcp-client cleanup

prg wrote:

[...]


BT has already mentioned dhclient -r.

no such flag in the version I am running.

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.

ok.


[...]


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.

sounds to me like the most plausible explanation.. ie. when I boot this system the script - ifupdown? - acquires a lease but somehow fails to configure the interface.. but when I try to obtain a new lease by running ifup eth0 dhclient is unable to acquire one. It looks like the server refuses to grant me one since I already have an unexpired lease acquired only a few minutes earlier.. Now on the other hand if I boot up.. and then remain inactive some six seven hours the server may decide after a while that it is time to reclaim the lease. So when I try again in the morning I have the clean situation that I was hoping to create by releasing the lease manually and so now I am able to configure the interface successfully by running ifup eth0. As I said I am only guessing but doesn't this make sense..? And what about this cable modem thing they gave me.. Does it just do low level stuff or does it understand some IP..?

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.

well this is cable from Optimum Online not dsl.. but I would imagine that regarding use and misuse of their resources they would have the same objectives/concerns as the phone companies. Or would the differences between dsl and cable make this argumentation irrelevant..??


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.

I certainly would not try doing this on a system with a working connection and risk losing that.. this was more of a see-what-happens kind of attitude.. and in any case I only copied over the lease file from the system that works to the system that does not. What I was trying to figure out was whether unable to obtain a lease from the server, dhclient would eventually use the unexpired lease recorded in the lease file and either connect me if it was still valid (wasn't counting on it..) or possibly issue some interesting messages if it failed. No luck either way, I'm afraid.


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.


ifup/down is a compiled program so I'd have to grab the source that corresponds to my particular version.


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

I did not write the above in earnest.. was venting my frustration.. after being stuck three weeks and not having made any progress I was trying to see the amusing side things.. I just could not believe that dhclient did not provide a means of ending the lease forcibly.. Not a bad ideea since the newer version apparently has this -r flag.

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

ok.



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

so I was on the right track. I did this with the faint hope of connecting the system.. but mostly to verify that I understood the dhclient doc correctly and that the program actually behaved as advertised.

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.

absolutely.. not sure I did the right thing to bring up the interface/network manually, though..

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.

I was not trying to get my connection to work just by haphazardly trying different things - I am not that optimistic - but since this is a new.. not even half-completed install and since I cannot download any tools.. can't even google for hints or comparable issues.. I was trying to cause the system to react and maybe come up with some error message that might help me find a solution.

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

Yes. I was doing a network installation and the debian installer did not find my 3com 3c574 nic. Instead it came up with a message to the effect that he had detected my laptop's firewire capabilities (a new one on me..) and maybe that's what I would like to use for my network connection.. I answered no.. was invited to choose among a list of network-related modules.. chose 3c574_cs.. was again informed that the installer couldn't find my nic etc.. but would I like to do the install via my firewire thing.. so eventually I answered yes to get out of the loop and skipped this step.. went on to the next one - partitioning the HD - and from there I was able to go back to the installer's main menu where I re-ran the "configure the network" step.. and this time the installer appeared to configure my NIC and bring up my connection.

Being somewhat cautious by nature I opened a shell.. ran ifconfig and my eth0 looked absolutely fine.. proceeded to ping a web site.. works fine - ok, so routing & resolver are operational.. I even go as far as far as wget-ing the www.debian.org home page. So where the network side of things is concerned the system loaded by the installer was fully functional - from the lower hardware layers.. irq.. cardbus.. pcmcia.. up to dns. The only thing I noticed that did not seem quite right is that usually the installer obtains a hostname from my isp - ool-something - and this time when the installer asked me for a hostname the field was blank.

Now although this initial stage of the install worked fine and a minimal system did get downloaded over my connection and installed on my hard drive the workaround above must have confused the installer and caused it to set up something broken/invalid in the network configuration of this new system.. which I experienced as soon as I re-booted to complete the install.. ifconfig only listed the looback interface.. routing was not configured and as a result I was unable to connect to the debian repositories at ftp.us.debian.org to download my favorite packages. Naturally I have checked everything regarding my pc card nic via the usual cardctl status commands.. verified that the usual lsmod culprits are loaded.. same as on the older sarge system and at this level everything looks fine - to my uneducated eyes at least..

Naturally I posted on the debian-user list re: the install problem but quiet as a mouse has everyone been.. filed a bug report eleven days ago.. no reply so far.. Maybe I am paranoid but I'm beginning to think that the maintainers know about this issue and just do not want to get involved at this point because they have other priorities.

Now another way of looking at this is that my fooling around with the installer did not really break anything.. It was just broken to begin with and the reason I was able to bring up the network by rerunning the "configure the network" step while my attempts at bringing up networking manually failed was that I did not do it right..

And that's why I figured that dhcp got screwed up when I booted and so I thought maybe I could fix that by telling the server to expire my lease.. and then just running ifup eth0 would bring up the network. Hey.. ya never know..!

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.

will probably use tcpdump since installing X on this system that does not connect properly is going to be a pain.

Compare their respective dhclient.conf files for differences
also.

since that wasn't too much work :-) that was one of the first things I did.. /etc/dhclient.conf is full of the same commented out stuff on both systems.. ie. both files are effectively empty..

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.

ok.. I guess I'll have to use ethereal on the sarge system to figure out the layout of the dhcp packets since I doubt tcpdump has this capability.. or the rfc's probably have that in an appendix..?

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?

I believe not.. but I'm not categorical..


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.


even for testing..? I would have thought this would give me more control and either confirm or eliminate the possibility that it's the etch networking scripts that mess things up..???


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

these live CD's are based on debian which in plain English means that they just copied over the installer.. init scripts.. system config files.. etc. warts and all.. differences appear to be mostly cosmetic in the way of a cute splash screen with a progerss bar while the system boots up but apart from that ubuntu and kubuntu live CD's have exactly the same ncurses setup screens as debian etch - the part where they ask for your keyboard layout.. time zone.. etc.

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

I've been rather careful.. but mostly because I'm not too sure of the implications and I would not want my ISP to think I'm messing with their network and cancel my service..

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,

... trouble is I did not configure anything on that system.. just found after a lot of digging that the new 2.6 hotplug thing that has replaced/generalized pcmcia was missing an "allow-hotplug eth0" statement in /etc/network/interfaces.. and it is after I added this that I was able to episodically bring up the connection.. Apart from that the only thing I can think of is bring up the network at a later stage in the boot process.. But I don't see how this could have any realtion to the fact that when I run dhclient manually I practically never manage to acquire a lease..

but often it requires some digging just to get the relavant clue.

I hear you.. :-)

Without time to chase down problems, and with so many distros out
there, I would just move on to another one.

No I really want to stick with debian because of its packaging system and I have too much on my plate right now to experiment with anything else.. too much overhead. As I told BT in my other post I have a couple of desktop type machines wilth multiple nic's that I am not using at this point and I could configure one as a gateway/router running debian stable. Sounds more productive.

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


Yes and no.. I really hate fixing these problems where you don't have any access to what's configured at the other end.. may teach you something re: self-control but hardly the best context to acquire any form of technical knowledge.. you usually end up with the thing working.. some clues as to why it did.. but nothing really solid.

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?


yes.. I do get an error message regarding pcmcia at startup that I have not had time to investigate and another one where the kernel says it was unable to unload 3c574_cs at shutdown.. Maybe there is a hardware issue lurking behind all this after all.

Thank you very much indeed for your help.
Chris.
.

Relevant Pages

  • ie 6.0
    ... > laptop moves from one network to another, its IP address lease might need ... > request might go to a different server that will not extend the lease ... > for a period of time, it will not provide the time to requesting clients. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: copy dhcp settings
    ... When the users have network issues your reputation as a network ... A single DHCP server could ... >> who believes it has a valid lease but that the new DHCP server knows ... I simply set the lease period ...
    (microsoft.public.windows.server.networking)
  • Re: Computer network question
    ... with another system on the network" in a popup message above the tray at ... Some other computer has to be the server. ... When set up properly you will tell the DHCP server what IP addresses are available as a range of available IPs. ... That becomes like a static IP address for your internal network (although it is usually not static...the ISP provides it as a dynamic lease, but I just think of it like a static for internal purposes). ...
    (rec.outdoors.rv-travel)
  • Re: Client drops network connection repeatedly
    ... Now how about the network patch cable from the PC ... check the logs on your ... accessing the network do) The DHCP log for the DHCP server that it leases ... the address from shows a pattern of repeated renewals of the lease before ...
    (microsoft.public.windows.server.networking)
  • Client drops network connection repeatedly
    ... I have a PC client on our WS2003 network that often drops its connection and crashes. ... The DHCP log for the DHCP server that it leases the address from shows a pattern of repeated renewals of the lease before it should have expired. ... If the computer is restarted then the event logs cease and as we can see a new DHCP lease is issued at that time. ...
    (microsoft.public.windows.server.networking)