Hello. I'm contacting you to inform you that pump doesn't work with
Passport switches' DHCP relay agent. In particular, the switch will relay
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
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
we've found them very unwilling to believe that it's something they're
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
*** dhcp.c Thu Dec 14 23:22:58 2000
--- dhcp.c-patched Thu Dec 14 23:23:19 2000
*** 1225,1230 ****
--- 1225,1234 ----
+ /* 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 */
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
User reports fixed sometime between 0.8.3 and 0.8.11.