I have Charter's Pipleline Internet in St. Louis, The new cable mdoem's are 3Com's 3-way cable modem- since 2-way service isn't available here ,the cable mdoems have a startard external analog modem which they use for outgoing connection, and a conenciton to the cable as well for incoming data. The cable modem has a built-in DHCP server and its own IP Address, when not conected to the 'Net, it assigns my comptuer a temporary IP address with a 5-second lease and fills /etc/resolv.conf with garbage (which cuased pump to segafult, but fixed in pump-0.70). Once anyone tries to do anything that requires a 'Net connection, the cable mdoem dials out at that point, and obtains a REAL IP adrress via DHCP (and valid DNS servers for /etc/resolv.conf). The problem is my comptuers IP address won't change with pump, even thoguh the cable modem has a new lease - it tries to renew the old, temporary 5-second lease (which it was reneewing repeatedly just fine until I actually connected to the 'Net) Pump basically hangs at that point, becasue it insists on renwing that adddres which isn't available anymore - pump need to obtain the NEW address when it can't renew the old one (And modify /etc/resolv.conf as well) . dhcpcd seems to handle this (though it start accumalating zombies each time my IP adress changed). Note that, once I turn off the analog external modem (I have only 1 line), the cable modem will start the temporary address again (the one with the 5-second lease) The only way to get this to work is to connect to the Internet (by typing something like ping www.redhat.com to force the cable modem to dial out), wait a few seconds, do a "killall pump", bring down the interface (if I try to bring down the interface while pump is running and I'm conencted to the Internet, it hangs), the bring back up the interface again - forcing pump to obtain a new lease - and it gets the newly, corect Internet one, and fills /etc/resolv.conf with the correct values. Note that because the temporary lease is only 5 seconds, this fils up my log fast and causes lots of HD activity if I'm not conencted to the 'Net, though pump isn't so bad as other dhcp cleints about this, but still... I am using pump 0.70.
All above problem stil exists in pump-0.7.2-2, a temporary workaround to stop the hanging on shutdown or reboot is to kill the pump process before the network goes down through a "psuedo-service" called killpump, which when "stopped" does a "killall pump". (Note it needs to be executed BEFORE the "Network" service goes down) WIth the new pump.conf file, pump seems to ignore the "retries" and "timeout" values when releasing an interface (so it still hangs when it tries to release an IP address to a DHCP server it can no longer reach, since the line is down. or for which the lease has changed) dhcpcd handles this changing-ip scheme just fine, except that it accumlates zombies with every IP change. But dhcpcd cannot be easily used in place of "pump" without a lot of mangling of the initscripts, or some kind of wrapper.
Pump 0.7.8 will not obtain a new lease (address) for an interface if the initial lease cannot be renewed after it expires. (It doesn't lock up anymore like previous versions did though). Normally this wouldn't be noticed as pump assumes as long as it's running, it will always be able to renew the lease. However, the DHCP server on my cable modem doesn't do this - it sometimes hands out leases that cannot be renewed, and thus a new lease must be obtained. When pump can't renew the lease, it doesn't try to obtain a new lease like other dhcp clients (dhcpcd, dhclient, and Windows as well). It just gives up on the interface. Somewhat contrived example: Pump would probably experience the same behavior if it were running on a laptop configured by 1 DHCP server, then connected to a different network, with a different DHCP server, and sat there until the orignial lease expired.
I think this is fixed in the pump in rawhide/pinstripe. Please let me know if it still exists. I can't build an exact test case here, so it's a bit hit and miss on reproducing it.
The problem still exists but the situation is little better now. Pump-0.8.2-1 does indeed obtain the new the lease (according to ethereal), unlike previous versions that just gave up. However, pump did not reconfigure the interface properly - it removed the old address but failed to put the new one on.
Created attachment 2637 [details] Packet capture of pump-0.8.2-1