Bug 40458

I've tested this problem with 3 different nics now (1 netgear fa310-tx(pnic) and
2 3com 3c905c's)

It will lose the ip after about 12 hours.

I'm going to try the same test with the pump from 7.0 next.

Has anyone seen any problems like this recently?

Ok I've confirmed that the lease is given up after the max-lease-time value is
expired (I set the default-lease-time to 600 and max-lease-time to 900) - the
nic stopped having an ip 15minutes afterwards.

I'm going to try pump from 7.0 now.

I've tried pump from rh 7.0 and it still has the same problem.

It seems like it could be something in the network config scripts that run after
pump renews its lease.
I'm going to look around in there now.

is anyone reading this? and/or have a suggestion on where to look?

To obtain debugging information make sure you have in /etc/syslog.conf something
like: daemon.* /var/log/daemon
Then restart the logging daemon: /etc/rc.d/init.d/syslog restart
Also, what is your pump version?

pump 0.8.11-1 from 7.1 and 0.8.3-2 from 7.0

and I've got daemon.debug set to pump.log

as far as I can tell its not pump but its something from initscripts that pump
is calling after it renews.

I'm working on that now.

I've changed the priority on this one b/c I can get it to happen EVERYTIME now.

I've gone through and added some debug checks into ifup-post and I can't figure
out where it is happening in there.

can someone tell me what the ordering is for what runs when pump gets a renewal?

-sv

What is your initscripts version?

current with 7.1 (5.83-1)

-sv

I am really curious how pump can die in this manner.
Can you post the log messages of pump at renewal?

There are no log messages at renewal.
I've watched the logs for a long time and I've gotten NOTHING from them.

pump is still running after it loses its address.
but I don't get anything new in the logs.

I'll attach the logs 

Created attachment 18510 [details]
pump's logs at debug level

In cannot see any request lease time in your log. Can you check that "pump -s"
shows the right renewal time? Also, after you loose your IP adress, what
information do you have with "ifconfig eth0" ?

The device is still up - but no line which reads:
Inet: 192.168.182.16 etc etc etc

it just vanishes.
pump -s reports that:

renewal time is 100 seconds from the lease time.
the expiration time is 200seconds away from the lease time.

after pump fails to get the address back pump -s does reports:
Operation Failed.

so clearly something is unhappy.

:)

What is amazing is that you don't have any log messages from pump when renewing
(it should display a dozen of lines for each message between client and server).
Can you see the messages with "tcpdump"? Also, the server should have sent a 600
seconds lease time (not 200s), or did I miss something?

I changed the max-lease-time to 200s - the default-lease-time to 100s (I didn't
want to wait as long to see it break :)

I'll check a tcpdump tomorrow.

In your logs, the server proposes a lease time of 6 seconds, and next 12 seconds
(after the client requested for lot much). Did you really set these values in
the dhcp server config? Otherwise, there may be a timing problem there...

where in the logs does it say that


the pertinent section of the dhcpd.conf file:
host wks-test {
        hardware ethernet <stuff here>;
 	fixed-address 192.168.182.16;
	next-server install.domain.com;
        server-identifier install.domain.com;
        filename "/export/install/linux/rh-7.1/ks/workstation";
        option domain-name "phy.duke.edu";
        default-lease-time 100; 
	max-lease-time 200;
}

bresp: vendor:  51   4 0x00 0x00 0x00 0xc
It means that the server proposes a 12 sec lease.
See: http://www.dhcp.org/rfc2132.html par. 9.2

odd - pump -s lists the time as being greater than 12 seconds.

so if its getting that from the server (which I will check in the leases file
tomorrow) then its not interepreting it correctly.

and why would this machine work perfectly with dhcpcd?

Can you give me exactly what is shown by "pump -s" ?

I can send you pump -s output tomorrow.

a possibility just hit me though.

this line in the dhcpd.conf file

next-server install.domain.com;

install.domain.com != the dhcpd server.
in the past next-server was needed for ks to look for a different place for its
ks.cfg over nfs.

could it be that next-server is now being listened to?
I've noticed some weird requests being blocked by the ipchains on the machine
that is install.domain.com.

ok I retract that.

its not next-server

its almost definitely server-identifier
which I think was being ignored by pump before this.

Ok its working now - it was server-identifier.

which makes sense considering what it means.

however, should pump have just started obeying it?

I'm going to close this bug but I think its worth noting