RE: [ECOS] [Fwd: FreeBSD network stack question]

["Daniel Helgason" <danielh at telus dot net>]

I haven't looked at this implementation but I have seen this behaviour in
other stacks. After the ARP request/reply, things are okay - right?

UDP isn't a guaranteed transport method so losing a packet is no biggie as
far as it is concerned. TCP would have noticed the first bit missing
(actually the SYN packet, I think) and would have retried.

I'm guessing you'll probably lose another UDP packet when/if the ARP entry
times out and gets removed.

+---------------------------------------
|  Daniel Helgason <danielh_AT_telus.net>


> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Barry
> Wealand
> Sent: Wednesday, October 19, 2005 03:25
> To: ecos-discuss@sourceware.org
> Subject: [ECOS] [Fwd: FreeBSD network stack question]
>
>
>
> Hello -
>
> We're working with a MIPS-like target, eCos 2.0, and the FreeBSD network
> stack.  I have a simple application that sends UDP messages to a host
> server process, which sends back a short acknowledgement for each.
> Message size can be varied - for the present problem, we're using a size
> of 2K bytes.  Of course, such messages must be fragmented before being
> transmitted over an ethernet link.
>
> If we collect a packet trace with tcpdump, we see an ARP request and ARP
> reply, then we see the 2nd segment of the first message - the first
> segment of the first message is never transmitted.  A little tracing
> with GDB has shown that:
>
> 1. udp_output calls ip_output
> 2. ip_output calls ether_output
> 3. ether_output calls arpresolve
> 4. arpresolve calls arprequest
> 5. arprequest sends the ARP request message (recurses into
> ether_output), then returns to arpresolve.
> 6. arpresolve apparently operates asynchronously, and returns 0,
> indicating that address resolution is not yet complete. (Meanwhile, in
> due time, an ARP reply is received, providing the needed remote host's
> ethernet address.)
> 7. ether_output returns 0 to ip_output, indicating no errors.  In
> effect, the first segment has been dropped.
> 8. ip_output believes that all is well with the first segment and
> proceeds to send the second.  By now, the ARP resolution process has
> completed, and the second segment is transmitted normally.
>
> Is this normal?  If not, do you have any idea what we might we be doing
> wrong that could lead to this behavior?
>
> Thanks!!
>
> Barry Wealand
> barry.wealand@lmco.com
>
>
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


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