This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: DHCP problem in application image
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Vijay Padiyar <vijay_padiyar at hotmail dot com>
- Cc: Andrew Lunn <andrew at lunn dot ch>,eCos Support <ecos-discuss at sources dot redhat dot com>,Nick Garnett <nickg at ecoscentric dot com>
- Date: Tue, 05 Oct 2004 08:19:33 -0600
- Subject: Re: [ECOS] DHCP problem in application image
- Organization: MLB Associates
- References: <BAY1-DAV9FRaqbC8wSA0004ef05@hotmail.com> <20040929102257.GB18964@lunn.ch> <BAY1-DAV8tFlmmlQ0800004f93a@hotmail.com> <20040929114303.GF18964@lunn.ch> <BAY1-DAV622ZhCl8aii00036eb6@hotmail.com> <20041005115153.GW7625@lunn.ch> <BAY1-DAV1r2UAaTzvb500069218@hotmail.com>
On Tue, 2004-10-05 at 08:03, Vijay Padiyar wrote:
> Hello Andrew
>
> Ya that's what I was referring to. In the high-level DHCP program code
> ('dhcp_prot.c' in 'packages/net/common/current/src'), the code is written to
> support the following program flow:
>
> Board DHCP Server
> ------------ -------------------
>
> DHCP INIT ----->
> <----- DHCP OFFER
> DHCP REQUEST ----->
> <----- DHCP ACK
>
> What we find from an Ethereal capture is that during the application image
> execution, the DHCP ACK is SIMPLY NOT THERE AT ALL! Our board transmits the
> DHCP REQUEST with the supplied IP address and waits for the DHCP ACK:
>
> -------------------------------------------------------------------
>
> while (1) {
> .
> switch ( *pstate ) {
> ..
> ..
> case DHCPSTATE_REQUESTING:
> // Just send what you got with a DHCPREQUEST in the message
> type.
> // then wait for an ACK in DHCPSTATE_REQUEST_RECV.
> ....
> break;
> ..
> case DHCPSTATE_REQUEST_RECV:
> // wait for an ACK or a NACK - retry by going back to
> // DHCPSTATE_REQUESTING; NACK means go back to INIT.
> ...
> break;
> ..
> ..
> } //switch (*pstate)
> .
> } //while (1)
>
> ------------------------------------------------------------------
>
> The code simply keeps repeating these loops till the maximum number of
> retries are exhausted. It keeps sending DHCP REQUEST broadcasts on the
> network, but there is no DHCP ACK from the DHCP server.
>
> This is contrary to the case with RedBoot. Here, the DHCP server promptly
> responds to the DHCP REQUEST with DHCP ACK and the IP address is bound to
> the board. Why doesn't this happen in the application image?
>
> With reference to your comment, there is NO DHCP ACK PACKET received by the
> board AT ALL; more specifically, none ever arrives on the network at all! So
> it's not a problem of the code dropping packets.
>
> This is what we're checking out. Thanks for your help!!
One interesting thing in these dumps is that there seem to be two DHCP
servers, each offering a different address (on the same subnet!) This
may be a source of problems/confusion.
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss