lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] TCP ACK not received - Probably due to seq no.


From: Gaurav Jain
Subject: Re: [lwip-users] TCP ACK not received - Probably due to seq no.
Date: Wed, 17 Feb 2016 12:14:01 +0530

Hi Sergio,
Thank you for your detailed help. I actually began from the beginning
and parsing step by step I understood the points and junctions at
which I had messed up a lot of concepts. Your answers were a guide at
every step. Thanks again

On Fri, Feb 12, 2016 at 6:40 PM, Sergio R. Caprile <address@hidden> wrote:
> Have you checked the tcp_write() return code ?
> Do you call tcp_sndbuf() to see what your available room is ? You seem
> to have said so in the first thread, so you actually get out of buffer
> space.
> Maybe you don't free your received pbufs.
> Do you know you have to wait for the other end to send ACKs so the stack
> can free your transmitted buffers and signal you can send more by means
> of the tcp_sent() callback ?
>
>> Once .10 starts sending data, after 300ms, the seq no it sends with is
>> 1 and the ACK field is 1461. However, .74 sends back an ACK with 9251.
>
> No, it is not, you are confusing seq numbers with ACK numbers, the
> sequence is correct as far as I understand how TCP works. Unfortunately
> I don't have the time nor is this the space for a TCP crash course.
> ACK numbers reflect the expected seq numbers for the next message from
> the other end. In frame 19, .10 is acknowledging it got data upto 9251
> (next data byte will be 9252) and sending 1446 bytes starting from 1 at
> the same time (piggybacked ACK).
>
> Regarding that jumbo frame, I don't know what stack is running on .74
> and why it does that.
> Furthermore, the fact that .10 issues to ACKs for that, one in frame 18
> and the other piggybacked in frame 19, makes me think that actually two
> frames got out and what we see is an artifact of the capture driver on
> .74 where you run wireshark because it is a PC or equivalent (what you
> don't say)
> I would check on .10 what it sees and why it can't transmit.
> You have statistics you can enable and see how memory pools are being
> handled.
> You can put breakpoints and check return codes.
> Your problem, IMO, is in your application, but there is a possibility
> you have a broken driver/port or something else.
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users



reply via email to

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