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

[Arnaud Chataignier]

May be you should try this patch, it may be related to your problem. I
think it has been incorporated in CVS from then , but may be you don't
have the latest version ?

http://sourceware.org/ml/ecos-patches/2005-06/msg00041.html

Regards,
Arnaud.

-----Message d'origine-----
De : ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] De la part de Barry
Wealand
Envoyé : mercredi 19 octobre 2005 12:25
À : ecos-discuss@sourceware.org
Objet : [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