Bug 7011 - Sending initial optionless discover fails on some @Home systems
Sending initial optionless discover fails on some @Home systems
Product: Red Hat Linux
Classification: Retired
Component: pump (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Erik Troan
Depends On:
  Show dependency treegraph
Reported: 1999-11-15 10:18 EST by hecker
Modified: 2008-05-01 11:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-23 15:51:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description hecker 1999-11-15 10:18:14 EST
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 15:51:59 EST
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.