Red Hat Bugzilla – Bug 31212
pump renews lease immediately with Allied Telesyn AR220E as DHCP Server
Last modified: 2007-04-18 12:32:05 EDT
The AR220E DSL/Cable modem router/firewall from allied telesyn gives unusual long lease times (24855 days, 12 hours, 20 minutes, 16 seconds, or 0x80008000). This happens at least with AR220E with the following firmware release: R1.07a Oct. 16, 2000 As pump uses a signed int for the lease time, this will give a negative lease time, so pump immediately renews the lease, which effectively hogs the network connection to the AR220E. The following patch fixes the problem: *** dhcp.c.orig Fri Mar 9 21:00:49 2001 --- dhcp.c Fri Mar 9 20:36:35 2001 *************** *** 1093,1099 **** } static void parseLease(struct bootpRequest * bresp, struct pumpNetIntf * intf) { ! int lease; time_t now; intf->set &= ~PUMP_INTFINFO_HAS_LEASE; --- 1093,1099 ---- } static void parseLease(struct bootpRequest * bresp, struct pumpNetIntf * intf) { ! unsigned int lease; time_t now; intf->set &= ~PUMP_INTFINFO_HAS_LEASE; I also notified Allied Telesyn about the problem. I asked them to make shorter lease times, as this large lease time will ask for trouble on systems moving between networks, or to make it configurable. Sincerely, Klaus Steinberger
Created attachment 31234 [details] Supporting evidence for my additional comments concerning this bug
Hello, I encountered the same problem with a SyGate server. (As well, I noticed a coding error in the packet logging code.) Here's what I prepared for submission just before your submission showed up. It includes: a more detailed description of the problem (including logs etc. to help whoever resolves these things to do some verification), probable cause of the problem (I don't have enough time to set up a build environment to verify it), and a proposed fix. In a nutshell: Pump was doing 300 lease renewals per second to my DHCP server. Upon looking into this, I found that my DHCP server hands out VERY LARGE lease times (e.g. 0xffffff7f) (yes, they messed up on network byte ordering :-) ). But, that should still be acceptable because RFC 1533 says "32-bit unsigned integer". Unfortunately, pump does signed arithmetic to determine whether or not a lease has expired yet. So, the lease appears to pump to have expired as soon as it has arrived. Granted, lease times above 0x7fffffff don't likely occur too often in practice, but it's a one line fix, so I thought you might be interested. Also, there's a coding error in the pump/dhcp code feeding syslog. Attached please find pump_prob.tar.gz, containing: - README: This file - pump-0.8.11-1.src.rpm: The rpm from which I extracted source to inspect (www.rpmfind.net gave it as the one for RedHat 7.1 for i386) - var_log_messages-excerpts: Excerpts from /var/log/messages showing roughly 18,000 lease renewals per minute - var_log_daemondebug-excerpts: Excerpts from /var/log/daemondebug (which I set up to capture debug level syslog output from pump) showing protocol details of the DHCP client - server interaction. I believe that: 1) pump.c lines 394 and 395: tv.tv_sec = intf[closest].renewAt - pumpUptime(); if (tv.tv_sec <= 0) { should be replaced by: if( (unsigned)(intf[closest].renewAt) <= (unsigned)(pumpUptime()) { 2) dhcp.c line 735: snprintf (vendor2, 27, "%s 0x%02x", vendor, *vndptr++); should be replaced by: snprintf (vendor2, 28, "%s 0x%02x", vendor, *vndptr++); Then the lines in daemondebug.log would have been: ... pumpd[950]: bresp: vendor: 51 4 0xff 0xff 0xff 0x7f instead of: ... pumpd[950]: bresp: vendor: 51 4 0xff 0xff 0xff 0x7 Please feel free to contact me with any questions. - Doug K
I think I've got all these in... Thanks for the info.