Bug 22319 - pump doesn't work with Nortel Passport DHCP relay agent.
Summary: pump doesn't work with Nortel Passport DHCP relay agent.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pump   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-14 23:19 UTC by Need Real Name
Modified: 2007-03-27 03:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-27 15:16:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2000-12-14 23:19:11 UTC
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 */
+       breq.vendor[6]=DHCP_TYPE_REQUEST;

        addVendorCode(&breq, DHCP_OPTION_SERVER, 4, &serverAddr.sin_addr);
        addVendorCode(&breq, DHCP_OPTION_REQADDR, 4, &bresp.yiaddr);

Comment 1 Need Real Name 2000-12-14 23:22:38 UTC
It should be noted that what pump does is somewhat unorthodox, but okay by RFC.
Nortel is broken, but...

Comment 2 Elliot Lee 2001-08-08 04:12:32 UTC
Ahahh, a patch to apply.

Apologies for the unresponsiveness of the previous pump packager...

Comment 3 Elliot Lee 2001-08-26 20:08:52 UTC
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...

Comment 4 Need Real Name 2001-08-27 15:16:31 UTC
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


Comment 5 Elliot Lee 2001-08-27 16:27:14 UTC
User reports fixed sometime between 0.8.3 and 0.8.11.

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