<div dir="ltr">Thank you.<br>It seems, that problem same as described by Gene Smith (<a href="http://www.rtems.com/ml/rtems-users/2008/august/msg00073.html" target="_blank">http://www.rtems.com/ml/rtems-users/2008/august/msg00073.html</a>)
in his post "Little Endian ARM fails on 1st TCP datagram". The reason
is that BYTE_ORDER BIG_ENDIAN defined during compiling TCP functions.<br><br><div class="gmail_quote">On Fri, Aug 29, 2008 at 9:47 AM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It is late and I don't know the message offhand.  But it is<br>
coming from netinet/tcp_debug.c so you can read the code<br>
and see what you think.  There are only a few calls to tcp_trace<br>
and if you have to put a print at all of the TA_DROP invocations<br>
you might learn something.<br>
<br>
My gut feeling is that the toolset got better between the two<br>
points and maybe optimized away something that should really<br>
be marked volatile.<br>
<br>
The fact you are getting packets at all says mostly it is working.<br>
Hopefully the pointer I gave will help you see what is not<br>
getting set correctly in the incoming packet.<br><br></blockquote></div><br></div>