Bug 7011

Summary: Sending initial optionless discover fails on some @Home systems
Product: [Retired] Red Hat Linux Reporter: hecker
Component: pumpAssignee: Erik Troan <ewt>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 6.1CC: edwinh, mattdm, randy, ryants, steve
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: http://www.hecker.org/misc/dhcp-athome/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-23 20:51:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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