Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7011 - Sending initial optionless discover fails on some @Home systems
Summary: Sending initial optionless discover fails on some @Home systems
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pump
Version: 6.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
URL: http://www.hecker.org/misc/dhcp-athome/
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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.