Bug 7011 - Sending initial optionless discover fails on some @Home systems
Summary: Sending initial optionless discover fails on some @Home systems
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pump
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
URL: http://www.hecker.org/misc/dhcp-athome/
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-15 15:18 UTC by hecker
Modified: 2008-05-01 15:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-23 20:51:48 UTC

Attachments (Terms of Use)

Description hecker 1999-11-15 15:18:14 UTC
Pump has been upgraded to support the -h option to supply a hostname, as
referenced in bug 2477. Unfortunately this change is not sufficient in and
of itself to have pump work properly on some @Home systems (in my case,
Comcast@Home in the Baltimore MD service area). I have identified the root
cause of the problem and have a tentative fix for it.

The problem appears to be that pump-0.7.2-2 always sends an initial DHCP
discover message without any options (hostname or otherwise), apparently in
an attempt to be compliant with the relevant DHCP RFC; only if pump
receives a DHCP offer in response to this initial message will it go on to
send a message with options (including hostname if specified).

Unfortunately the DHCP servers on my local @Home network ignore this
initial discover message (presumably because the message does not contain a
hostname) and do not respond to it; pump then retries sending the initial
optionless discover message and eventually times out with a failure to
configure the interface.  See <URL:http://www.hecker.org/misc/dhcp-athome/>
for tcpdump data and syslog messages (at DEBUG level) from such an
unsuccessful attempt.

I was able to get pump to work on my local @Home network by hacking in a
new command line option --skip-initial-discover; see the URL above for the
diffs. If included on the command line this new option causes pump to skip
sending the initial optionless discover message and immediately send a
discover message with options. (This is the same message that would have
been sent as the second discover message in "normal" operation.)  This mode
of operation appears to work properly: the @Home DHCP servers respond to
the discover message with options, and the interface is configured
correctly and can be used; see the URL referenced above for tcpdump data
and syslog messages from a successful attempt.

This may not be the best fix possible. The best way to do this in general
may be to try the initial discover message a few times, and then if
unsuccessful (i.e., no response was made) fall back to sending a discover
message with options. This would remove the need for a special command
line, although it may not be totally compliant with the DHCP RFC. If the
need for a command line option remains then you need to make corresponding
changes to /sbin/ifup to include the option when invoking pump.

Comment 1 Erik Troan 2000-02-23 20:51:59 UTC
Thanks for the details on this -- it's all fixed in pump 0.7.8, which is
available from ftp://people.redhat.com/ewt

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