[ECOS] DHCP problem in application image

["Vijay Padiyar" <vijay_padiyar at hotmail dot com>]

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!!

Regards

Chandrashekhar Padiyar

P.S.: Attached are the RedBoot and application image Ethereal data captures.
VIEW IN ETHEREAL ONLY.



----- Original Message -----
From: "Andrew Lunn" <andrew@lunn.ch>
To: "Vijay Padiyar" <vijay_padiyar@hotmail.com>
Cc: "eCos Support" <ecos-discuss@sources.redhat.com>
Sent: Tuesday, October 05, 2004 5:21 PM
Subject: Re: [ECOS] Error: Socket was forcibly closed by remote host


> On Tue, Oct 05, 2004 at 05:11:37PM +0530, Vijay Padiyar wrote:
> > Hi all
> >
> > Well we analyzed the network data with Ethereal. We find that during the
> > Redboot initialization, the DHCP protocol works fine. The flow is as
> > follows:
> >
> > Board                                    DHCP Server
> > ------------                          -------------------
> >
> > DHCP INIT             ----->
> >                                 <-----     DHCP OFFER
> > DHCP REQUEST   ----->
> >                                 <-----     DHCP ACK
> >
> > But during the application image execution, the DHCP phase goes as
follows:
> >
> > Board                                    DHCP Server
> > ------------                          -------------------
> >
> > DHCP INIT             ----->
> >                                 <-----     DHCP OFFER
> > DHCP REQUEST   ----->
> >                             (TIMEOUT)
> > DHCP REQUEST   ----->
> >                             (TIMEOUT)
> > ..
> > ..
> > ..
> > "BOOTP/DHCP Failed on eth1"
>
> Have you tried actually debugging the problem? Is the packet received
> by the ethernet driver? Does it get passed into the IP stack? Does the
> IP stack pass it to the bootp code?
>
> Once you have found out where the packet gets dropped you will be half
> way to solving your problem.
>
>         Andrew
>

Attachment: redboot.out
Description: Binary data

Attachment: application.out
Description: Binary data

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss