[Bug 1000053] New: RedBoot fails to get DHCP address correctly

[bugzilla at ecoscentric dot com]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000053

           Summary: RedBoot fails to get DHCP address correctly
           Product: eCos
           Version: CVS
          Platform: All
               URL: http://www.faqs.org/rfcs/rfc2131.html
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: normal
         Component: RedBoot
        AssignedTo: gary@mlbassoc.com
        ReportedBy: jifl@ecoscentric.com
         QAContact: ecos-bugs@sources.redhat.com


A recent change to RedBoot's bootp.c fixed the use of a DHCP option to use
DHCPDISCOVER instead of DHCPREQUEST. However it turns out this patch was
incomplete. RFC2131 says the exchange has to be DHCPDISCOVER from client,
DHCPOFFER from server, DHCPREQUEST from client, DHCPACK from server. RedBoot
stops after getting the DHCPOFFER. As a result DHCP servers now don't actually
assign the lease to RedBoot.

This is in fact a retrograde step because at least in the past, the DHCP server
would at least assign a BOOTP address, but by now using (correctly) the
DHCPDISCOVER first, a server that serves both BOOTP and DHCP will now only
return from the BOOTP allocation. As a result, the DHCP address could be
reassigned, even if users have set it up with an infinite (or sufficiently long)
lease as they would need to since redboot doesn't have a thread to renew the lease.

So RedBoot should instead continue the exchange to do the formal DHCPREQUEST and
wait for the DHCPACK. This whole thing (use of a DHCP option) should probably be
made configurable anyway so plain old BOOTP can be used on its own. I believe
the only reason for the DHCP option to be present is to get assigned addresses
from DHCP servers that _can't_ do BOOTP.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.