This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 11306 - Pump not configuring DHCP address
Pump not configuring DHCP address
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: pump (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-08 15:54 EDT by Bill Stephens
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-04 11:18:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Stephens 2000-05-08 15:54:32 EDT
Both during a network install and on a fully installed RH 6.2 server, Pump
fails to obtain and configure DHCP addressing information.  Complete
information from logs, display etc. = "operation failed".  I have a
windoze client on the same network, and sitting next to the RedHat server
that receives its dhcp information without fail.  If I assign a static IP
address, the adapter functions without any problems.  It doesn't appear to
be hardware related, or bootp forwarding related.  My hardware
configuration is as follows for both the windoze and RH servers:

Dell 2300
256 Mb memory
3-9.1 gb hard drives
AMI Megaraid controller
IBM PCI Token-Ring (statically assigned address) tr0
3com 3c905b-tx (wanna be dynamic) eth0
Also tried 3c905c-tx ethernet cards, same problem.
Comment 1 Bill Stephens 2000-05-11 13:27:59 EDT
I have performed several sniffer traces on the transaction.  Basically here's
what's happening:

DHCP Client -> DHCP Request
DHCP Client <- DHCP Offer from BootP forwarding Router from DHCP server
DHCP Client Ignores offer
DHCP Client -> Bootp request

Is there any way to figure out why pump is ignoring the IP address being
offered?  I've checked the address being offered, and it is valid.  No one else
is using the IP address.

BTW is anyone there?  Has anyone seen this problem request?

Thanks,

Bill Stephens
bill.stephens@fritolay.com
Comment 2 Bill Stephens 2000-05-11 14:19:59 EDT
I turned on the syslog debugging for pump.  Here's the output.  You can see
that pump recognizes he's getting a valid offer, and then just ignoring it.

                        May 11 12:55:17 us381s04 pumpd[835]: breq: opcode: 1
May 11 12:55:17 us381s04 pumpd[835]: breq: hw: 1
May 11 12:55:17 us381s04 pumpd[835]: breq: hwlength: 6
May 11 12:55:17 us381s04 pumpd[835]: breq: hopcount: 0
May 11 12:55:17 us381s04 pumpd[835]: breq: id: 0x0f4b7656
May 11 12:55:17 us381s04 pumpd[835]: breq: secs: 0
May 11 12:55:17 us381s04 pumpd[835]: breq: flags: 0x0000
May 11 12:55:17 us381s04 pumpd[835]: breq: ciaddr: 0.0.0.0
May 11 12:55:17 us381s04 pumpd[835]: breq: yiaddr: 0.0.0.0
May 11 12:55:17 us381s04 pumpd[835]: breq: server_ip: 0.0.0.0
May 11 12:55:17 us381s04 pumpd[835]: breq: bootp_gw_ip: 0.0.0.0
May 11 12:55:17 us381s04 pumpd[835]: breq: hwaddr:
May 11 12:55:17 us381s04 pumpd[835]: breq: servername:
May 11 12:55:17 us381s04 pumpd[835]: breq: bootfile:
May 11 12:55:17 us381s04 pumpd[835]: breq: vendor: 0x63 0x53 0x82 0x63
May 11 12:55:17 us381s04 pumpd[835]: breq: vendor:  53   1 0x01
May 11 12:55:17 us381s04 pumpd[835]: breq: vendor: 0xff
May 11 12:55:21 us381s04 pumpd[835]: bresp: opcode: 2
May 11 12:55:21 us381s04 pumpd[835]: bresp: hw: 1
May 11 12:55:21 us381s04 pumpd[835]: bresp: hwlength: 6
May 11 12:55:21 us381s04 pumpd[835]: bresp: hopcount: 1
May 11 12:55:21 us381s04 pumpd[835]: bresp: id: 0x0f4b7656
May 11 12:55:21 us381s04 pumpd[835]: bresp: secs: 0
May 11 12:55:21 us381s04 pumpd[835]: bresp: flags: 0x0000
May 11 12:55:21 us381s04 pumpd[835]: bresp: ciaddr: 0.0.0.0
May 11 12:55:21 us381s04 pumpd[835]: bresp: yiaddr: 156.82.199.140
May 11 12:55:21 us381s04 pumpd[835]: bresp: server_ip: 0.0.0.0
May 11 12:55:21 us381s04 pumpd[835]: bresp: bootp_gw_ip: 156.82.199.1
May 11 12:55:21 us381s04 pumpd[835]: bresp: hwaddr:
May 11 12:55:21 us381s04 pumpd[835]: bresp: servername:
May 11 12:55:21 us381s04 pumpd[835]: bresp: bootfile:
May 11 12:55:21 us381s04 pumpd[835]: bresp: vendor: 0x63 0x53 0x82 0x63
May 11 12:55:21 us381s04 pumpd[835]: bresp: vendor:  53   1 0x02
May 11 12:55:21 us381s04 pumpd[835]: bresp: vendor:  54   4 0x9c 0x51 0x14 0x7
May 11 12:55:21 us381s04 pumpd[835]: bresp: vendor:  51   4 0x00 0x00 0x1c 0x2
May 11 12:55:21 us381s04 pumpd[835]: bresp: vendor:  58   4 0x00 0x00 0x0e 0x1
May 11 12:55:21 us381s04 pumpd[835]: bresp: vendor: 0xff
May 11 12:55:21 us381s04 pumpd[835]: got dhcp offer
May 11 12:55:21 us381s04 pumpd[835]: PUMP: sending second discover
May 11 12:55:21 us381s04 pumpd[835]: breq: opcode: 1
May 11 12:55:21 us381s04 pumpd[835]: breq: hw: 1
May 11 12:55:21 us381s04 pumpd[835]: breq: hwlength: 6
May 11 12:55:21 us381s04 pumpd[835]: breq: hopcount: 0
May 11 12:55:21 us381s04 pumpd[835]: breq: id: 0x0f4b7656
May 11 12:55:21 us381s04 pumpd[835]: breq: secs: 0
May 11 12:55:22 us381s04 pumpd[835]: breq: flags: 0x0000
May 11 12:55:22 us381s04 pumpd[835]: breq: ciaddr: 0.0.0.0
May 1112:55:22 us381s04 pumpd[835]: breq: yiaddr: 0.0.0.0
May 11 12:55:22 us381s04 pumpd[835]: breq: server_ip: 0.0.0.0
May 11 12:55:22 us381s04 pumpd[835]: breq: bootp_gw_ip: 0.0.0.0
May 11 12:55:22 us381s04 pumpd[835]: breq: hwaddr:
May 11 12:55:22 us381s04 pumpd[835]: breq: servername:
May 11 12:55:22 us381s04 pumpd[835]: breq: bootfile:
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor: 0x63 0x53 0x82 0x63
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor:  57   2 0x02 0x24
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor:  55  11 0x01 0x03 0x06 0x0
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor: ++++++ 0x1c 0x0c 0x07 0x09
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor: ++++++ 0x2a 0x30 0x31
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor:  12   9 0x75 0x73 0x33 0x3
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor: ++++++ 0x31 0x73 0x30 0x34
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor: ++++++ 0x00
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor:  51   4 0x00 0x00 0xa8 0xc
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor:  53   1 0x01
May 11 12:55:22 us381s04 pumpd[835]: breq: vendor: 0xff
May 11 12:55:51 us381s04 pumpd[835]: PUMP: sending discover
May 11 12:55:51 us381s04 pumpd[835]: breq: opcode: 1
May 11 12:55:51 us381s04 pumpd[835]: breq: hw: 1
May 11 12:55:51 us381s04 pumpd[835]: breq: hwlength: 6
May 11 12:55:51 us381s04 pumpd[835]: breq: hopcount: 0
May 11 12:55:51 us381s04 pumpd[835]: breq: id: 0x0f4b7634
May 11 12:55:51 us381s04 pumpd[835]: breq: secs: 0
May 11 12:55:51 us381s04 pumpd[835]: breq: flags: 0x0000
May 11 12:55:51 us381s04 pumpd[835]: breq: ciaddr: 0.0.0.0
May 11 12:55:51 us381s04 pumpd[835]: breq: yiaddr: 0.0.0.0
May 11 12:55:51 us381s04 pumpd[835]: breq: server_ip: 0.0.0.0
May 11 12:55:51 us381s04 pumpd[835]: breq: bootp_gw_ip: 0.0.0.0
May 11 12:55:51 us381s04 pumpd[835]: breq: hwaddr:
May 11 12:55:51 us381s04 pumpd[835]: breq: servername:
May 11 12:55:51 us381s04 pumpd[835]: breq: bootfile:
May 11 12:55:51 us381s04 pumpd[835]: breq: vendor: 0x63 0x53 0x82 0x63
May 11 12:55:51 us381s04 pumpd[835]: breq: vendor:  53   1 0x01
May 11 12:55:51 us381s04 pumpd[835]: breq: vendor: 0xff
May 11 12:55:54 us381s04 pumpd[835]: bresp: opcode: 2
May 11 12:55:54 us381s04 pumpd[835]: bresp: hw: 1
May 11 12:55:54 us381s04 pumpd[835]: bresp: hwlength: 6
May 11 12:55:54 us381s04 pumpd[835]: bresp: hopcount: 1
May 11 12:55:54 us381s04 pumpd[835]: bresp: id: 0x0f4b7634
May 11 12:55:54 us381s04 pumpd[835]: bresp: secs: 0
May 11 12:55:54 us381s04 pumpd[835]: bresp: flags: 0x0000
May 11 12:55:54 us381s04 pumpd[835]: bresp: ciaddr: 0.0.0.0
May 11 12:55:54 us381s04 pumpd[835]: bresp: yiaddr: 156.82.199.140
May 11 12:55:54 us381s04 pumpd[835]: bresp: server_ip: 0.0.0.0
May 11 12:55:54 us381s04 pumpd[835]: bresp: bootp_gw_ip: 156.82.199.1
May 11 12:55:54 us381s04 pumpd[835]: bresp: hwaddr:
May 11 12:55:54 us381s04 pumpd[835]: bresp: servername:
May 11 12:55:54 us381s04 pumpd[835]: bresp: bootfile:
May 11 12:55:54 us381s04 pumpd[835]: bresp: vendor: 0x63 0x53 0x82 0x63
May 11 12:55:54 us381s04 pumpd[835]: bresp: vendor:  53   1 0x02
May 11 12:55:54 us381s04 pumpd[835]: bresp: vendor:  54   4 0x9c 0x51 0x14 0x7
May 11 12:55:54 us381s04 pumpd[835]: bresp: vendor:  51   4 0x00 0x00 0x1c 0x2
May 11 12:55:54 us381s04 pumpd[835]: bresp: vendor:  58   4 0x00 0x00 0x0e 0x1
May 11 12:55:54 us381s04 pumpd[835]: bresp: vendor: 0xff
May 11 12:55:54 us381s04 pumpd[835]: got dhcp offer
May 11 12:55:54 us381s04 pumpd[835]: PUMP: sending second discover
May 11 12:55:54 us381s04 pumpd[835]: breq: opcode: 1
May 11 12:55:54 us381s04 pumpd[835]: breq: hw: 1
May 11 12:55:54 us381s04 pumpd[835]: breq: hwlength: 6
May 11 12:55:54 us381s04 pumpd[835]: breq: hopcount: 0
May 11 12:55:54 us381s04 pumpd[835]: breq: id: 0x0f4b7634
May 11 12:55:54 us381s04 pumpd[835]: breq: secs: 0
May 11 12:55:54 us381s04 pumpd[835]: breq: flags: 0x0000
May 11 12:55:54 us381s04 pumpd[835]: breq: ciaddr: 0.0.0.0
May 11 12:55:54 us381s04 pumpd[835]: breq: yiaddr: 0.0.0.0
May 11 12:55:54 us381s04 pumpd[835]: breq: server_ip: 0.0.0.0
May 11 12:55:54 us381s04 pumpd[835]: breq: bootp_gw_ip: 0.0.0.0
May 11 12:55:54 us381s04 pumpd[835]: breq: hwaddr:
May 11 12:55:54 us381s04 pumpd[835]: breq: servername:
May 11 12:55:54 us381s04 pumpd[835]: breq: bootfile:
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor: 0x63 0x53 0x82 0x63
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor:  57   2 0x02 0x24
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor:  55  11 0x01 0x03 0x06 0x0
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor: ++++++ 0x1c 0x0c 0x07 0x09
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor: ++++++ 0x2a 0x30 0x31
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor:  12   9 0x75 0x73 0x33 0x3
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor: ++++++ 0x31 0x73 0x30 0x34
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor: ++++++ 0x00
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor:  51   4 0x00 0x00 0xa8 0xc
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor:  53   1 0x01
May 11 12:55:54 us381s04 pumpd[835]: breq: vendor: 0xff
Comment 3 Bill Stephens 2000-05-12 10:30:59 EDT
Ok, so this went nowhere.  I've fixed the problem in your code, and now pump
works.  Since you didn't respond, and you obviously have many other users with
the problem, but you're ignoring me, I won't bother letting you know what the
fix is, until you actually get around to responding to me.

Thanks

Bill
Comment 4 Erik Troan 2000-05-12 10:47:59 EDT
I'm glad you got this fixed -- sorry for the slow response, but I normally
handle pump bugs reports en mass, rather then one at a time. They tend to
take a lot of investigation with people who don't know what a tcpdump is
and handling them on a one-off basis is impractical.

I'd apreciate getting your patch and I'm glad you got this fixed.
Comment 5 Eric Doutreleau 2000-05-19 10:19:59 EDT
Well
I have exactly the same problem.
would u be nice to share with us the fix you have?

Thanks in advance
Comment 6 Bill Stephens 2000-05-23 11:00:59 EDT
Here's my crude hack at a diff file I used to resolve my issue.  Apply the diff
to the DHCP.c which comes with pump 0.7.8

-Bill

--- pump-0.7.8/dhcp.c	Tue Feb 15 14:59:11 2000
+++ pump-0.7.8-patch/dhcp.c	Fri May 12 08:51:53 2000
@@ -1090,7 +1090,7 @@
     struct sockaddr_in clientAddr;
     struct sockaddr_in broadcastAddr;
     struct bootpRequest breq, bresp;
-    struct bootpRequest protoReq;
+    //   struct bootpRequest protoReq;
     unsigned char * chptr;
     unsigned char messageType;
     time_t startTime = pumpUptime();
@@ -1132,6 +1132,29 @@

     messageType = DHCP_TYPE_DISCOVER;
     addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType);
+
+    aShort = ntohs(sizeof(struct bootpRequest));
+	addVendorCode(&breq, DHCP_OPTION_MAXSIZE, 2, &aShort);
+
+	numOptions = 0;
+	optionsRequested[numOptions++] = BOOTP_OPTION_NETMASK;
+	optionsRequested[numOptions++] = BOOTP_OPTION_GATEWAY;
+	optionsRequested[numOptions++] = BOOTP_OPTION_DNS;
+	optionsRequested[numOptions++] = BOOTP_OPTION_DOMAIN;
+	optionsRequested[numOptions++] = BOOTP_OPTION_BROADCAST;
+	addVendorCode(&breq, DHCP_OPTION_OPTIONREQ, numOptions,
+		      optionsRequested);
+
+	if (reqHostname) {
+	    syslog(LOG_DEBUG, "HOSTNAME: requesting %s\n", reqHostname);
+	    addVendorCode(&breq, BOOTP_OPTION_HOSTNAME, strlen(reqHostname) +1,
+			  reqHostname);
+	}
+
+	i = htonl(intf->reqLease);
+	addVendorCode(&breq, DHCP_OPTION_LEASE, 4, &i);
+
+

     if (reqHostname) {
 	syslog(LOG_DEBUG, "HOSTNAME: requesting %s\n", reqHostname);
@@ -1184,12 +1207,21 @@
 	/* Admittedly, this seems a bit odd. If we find a dhcp server, we
 	   rerun the dhcp discover broadcast, but with the proper option
 	   field this time. This makes me rfc compliant. */
-	syslog (LOG_DEBUG, "got dhcp offer\n");
+	syslog (LOG_DEBUG, "PUMP: got an offer");

 	initVendorCodes(&breq);

-	aShort = ntohs(sizeof(struct bootpRequest));
-	addVendorCode(&breq, DHCP_OPTION_MAXSIZE, 2, &aShort);
+//	aShort = ntohs(sizeof(struct bootpRequest));
+//	addVendorCode(&breq, DHCP_OPTION_MAXSIZE, 2, &aShort);
+
+	if (getVendorCode(&bresp, DHCP_OPTION_SERVER, &serverAddr.sin_addr)) {
+	    syslog (LOG_DEBUG, "DHCPOFFER didn't include server address");
+	    intf->bootServer = broadcastAddr.sin_addr;
+	}
+
+	messageType = DHCP_TYPE_REQUEST;
+	addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType);
+

 	numOptions = 0;
 	optionsRequested[numOptions++] = BOOTP_OPTION_NETMASK;
@@ -1197,7 +1229,7 @@
 	optionsRequested[numOptions++] = BOOTP_OPTION_DNS;
 	optionsRequested[numOptions++] = BOOTP_OPTION_DOMAIN;
 	optionsRequested[numOptions++] = BOOTP_OPTION_BROADCAST;
-	optionsRequested[numOptions++] = BOOTP_OPTION_HOSTNAME;
+//	optionsRequested[numOptions++] = BOOTP_OPTION_HOSTNAME;
 	optionsRequested[numOptions++] = DHCP_OPTION_LOGSRVS;
 	optionsRequested[numOptions++] = DHCP_OPTION_LPRSRVS;
 	optionsRequested[numOptions++] = DHCP_OPTION_NTPSRVS;
@@ -1206,7 +1238,7 @@
 	addVendorCode(&breq, DHCP_OPTION_OPTIONREQ, numOptions,
 		      optionsRequested);

-	if (!reqHostname) {
+/*	if (!reqHostname) {
 	    reqHostname = alloca(200);
 	    gethostname(reqHostname, 200);
 	    if (!strcmp(reqHostname, "localhost") ||
@@ -1224,12 +1256,13 @@

 	protoReq = breq;

-	syslog (LOG_DEBUG, "PUMP: sending second discover");
+	syslog (LOG_DEBUG, "Bubba: sending second discover");

 	messageType = DHCP_TYPE_DISCOVER;
 	addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType);

-	/* Send another DHCP_REQUEST with the proper option list */
+	 Send another DHCP_REQUEST with the proper option list
+
 	if ((chptr = handleTransaction(s, override, &breq, &bresp,
 				       &broadcastAddr, NULL, 0,
 				       DHCP_TYPE_OFFER))) {
@@ -1255,7 +1288,7 @@
 	breq = protoReq;
 	messageType = DHCP_TYPE_REQUEST;
 	addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType);
-
+  */
 	addVendorCode(&breq, DHCP_OPTION_SERVER, 4, &serverAddr.sin_addr);
 	addVendorCode(&breq, DHCP_OPTION_REQADDR, 4, &bresp.yiaddr);
Comment 7 Erik Troan 2000-08-04 11:18:21 EDT
So, what I think it really happening here is that your dhcp server isn't
responding to queries in which the option type isn't the first vendor code.
pump-0.8 (which will be out today) fixes this (thanks to bug report #14719). If
this fixes your problems, please let me know.
Comment 8 Erik Troan 2000-08-07 09:33:18 EDT
Reporter confirmed that pump-0.8 fixes this problem.

Note You need to log in before you can comment on or make changes to this bug.