lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Understanding retransmission


From: Jan Menzel
Subject: Re: [lwip-users] Understanding retransmission
Date: Tue, 20 Jan 2015 14:19:20 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Hi Simon!

On 19.01.2015 20:30, Jan Menzel wrote:
> On 19.01.2015 17:31, Simon Goldschmidt wrote:
>> "Jan Menzel" wrote:
>>> Your patch is already part of my code. I just disabled
>>> LWIP_CHECKSUM_ON_COPY and have not seen a bad packet since then.
>>
>> Great to hear that! Although LWIP_CHECKSUM_ON_COPY is not enabled by 
>> default, are you in a position to debug this?
>>
>> This should trigger the point where it fails:
>> #define LWIP_CHECKSUM_ON_COPY          1
>> #define TCP_CHECKSUM_ON_COPY_SANITY_CHECK 1
>> #define TCP_CHECKSUM_ON_COPY_SANITY_CHECK_FAIL(msg) 
>> LWIP_ASSERT("TCP_CHECKSUM_ON_COPY_SANITY_CHECK_FAIL", 0)
>>
>> And you could then see what was enqueued by setting this:
>> #define TCP_OUTPUT_DEBUG  (LWIP_DBG_ON | LWIP_DBG_TRACE)
>> #define LWIP_DBG_TYPES_ON         (LWIP_DBG_ON|LWIP_DBG_TRACE)
>>
>> That would be great!
>>
> I've tried my very best, but I'm not sure if I captured what you need.
> Please find some Wireshark frames together with corresponding log output
> and lwip options file. I also captured lwip statistics in case thats of
> any relevance. Maybe I did not enabled all options as I have not seen
> the ASSERT() message.
>       I'm not sure thats exactly going on. It seems that under very special
> conditions, the checksum of outgoing TCP packets gets corrupted and is
> also used for all retransmission.
>       If you need anything else, please let me know. In the mean while I'll
> try to force all outgoing checksums to be recomputed to get my project
> back online.
> 
Today I discovered some more interesting points about the TCP checksum
problem: the content of the packet sometimes changes with each
retransmission. The first as lost of zeros at the end. The later one
less zeros and - unfortunately not in the capture I send you - I've seen
retransmissions without zeros and correct checksum. This is something I
don't understand at all:
a) If there is any memory problem, I would assume, that the packet
content gets worth every retransmission.
b) If there is any DMA problem (pbuf is send to EMAC using DMA on
LPC1768) I would assume some DMA errors but not all zero content.
        Do you have any idea whats going on there?

        Jan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]