Hello. I'm contacting you to inform you that pump doesn't work with Nortel's Passport switches' DHCP relay agent. In particular, the switch will relay the initial request, but the second DHCP_DISCOVER message has the message type at the end of the option set and the switch does not forward this message, thus the client never receives an address. Reordering the options in the second request so that the message type (DHCP_DISCOVER) appears at the start instead of the end resolves this problem. Nortel is also aware but we've found them very unwilling to believe that it's something they're doing wrong (we even had an engineer on site today to observe it). It may affect others with Nortel equipment. The patch below (applied against pump-0.8.3) provides a work-around as descrbed above: *** dhcp.c Thu Dec 14 23:22:58 2000 --- dhcp.c-patched Thu Dec 14 23:23:19 2000 *************** *** 1225,1230 **** --- 1225,1234 ---- initVendorCodes(&breq); + /* This goes; here to make Nortel Passport 8010 happy - tschroed */ + messageType = DHCP_TYPE_DISCOVER; + addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType); + aShort = ntohs(sizeof(struct bootpRequest)); addVendorCode(&breq, DHCP_OPTION_MAXSIZE, 2, &aShort); *************** *** 1265,1273 **** syslog (LOG_DEBUG, "PUMP: sending second discover"); - messageType = DHCP_TYPE_DISCOVER; - addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType); - /* Send another DHCP_REQUEST with the proper option list */ if ((chptr = handleTransaction(s, override, &breq, &bresp, &broadcastAddr, NULL, 0, --- 1269,1274 ---- *************** *** 1292,1299 **** --- 1293,1305 ---- } breq = protoReq; + /* Can't do this because message order has changed... messageType = DHCP_TYPE_REQUEST; addVendorCode(&breq, DHCP_OPTION_TYPE, 1, &messageType); + */ + /* Cheap hack starts now... We assume that the message type is the first field - tschroed */ + breq.vendor[6]=DHCP_TYPE_REQUEST; + addVendorCode(&breq, DHCP_OPTION_SERVER, 4, &serverAddr.sin_addr); addVendorCode(&breq, DHCP_OPTION_REQADDR, 4, &bresp.yiaddr);
It should be noted that what pump does is somewhat unorthodox, but okay by RFC. Nortel is broken, but...
Ahahh, a patch to apply. Apologies for the unresponsiveness of the previous pump packager...
My lack of DHCP clues is preventing me from properly interpreting this patch. I'm worried that it will just wind up breaking other systems. Can you comment, and also perhaps provide a patch that will apply cleanly against pump-0.8.13? Thanks, sorry for the complication...
Sure, what's going on is this: DHCP messages have a generic buffer containing a set of options. The format of it is a bunch of elements in the form <type,arglen,argument>. One of these options must be a DHCP message type option which describes what type of message this is (discover, offer, request, etc). While it's not required by RFC, typically this is the first option in the set. Pump doesn't do it that way. What pump does is have a "proto request" which has a standard set of options that a pump client would be looking for. First pump sends out a DHCP message that could be either a DHCP discover or a BOOTP request. If the response it gets back comes from a DHCP server (as determined by looking for a magic number), pump copies that proto request into a full-fledged DHCP discover message and sends it again. However, in the first discover message, there was only one option, the message type. In this one, there are many options inherited from the proto request. pump appends the message type option to the end of the proto request's set. Now it's no longer first, it's last and the Nortel forwarding agent doesn't understand it. The issue arises because pump tries to do something valid but unexpected for performance's/convenience's sake (after receiving an offer from a DHCP server it can take that same proto request and this time tack on a message type option set to DHCP_REQUEST--it takes just a couple lines of code). The patch I submitted instead insures that the message type is the first option in the set. It simply makes pump behave like more conventional DHCP clients. I would make a 0.8.13 patch, but I can't seem to find the source code anywhere. -t.
User reports fixed sometime between 0.8.3 and 0.8.11.