buglwIP - A Lightweight TCP/IP stack - Bugs: bug #27904, TCP sends too many ACKs


You are not allowed to post comments on this tracker with your current authentication level.

bug #27904: TCP sends too many ACKs

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Sun 01 Nov 2009 05:17:39 PM UTC  
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Wed 02 Dec 2009 05:02:00 PM UTC, comment #5: 

Checked in.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 02 Dec 2009 09:15:15 AM UTC, comment #4: 

Sounds OK to me

Kieran Mansley <kieranm>
Project Member
Tue 01 Dec 2009 05:50:48 PM UTC, comment #3: 

So, anyone against this going in to 1.3.2?

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Fri 13 Nov 2009 12:50:53 PM UTC, comment #2: 

Disregard my comment.  I went back through the patch and my source and I was missing a piece of the patch.  Chalk this up to user error.  After making sure all of the patch was placed in the correct locations, everything works correctly.


Dustin Stahlback <dstahlback>
Fri 13 Nov 2009 12:43:14 PM UTC, comment #1: 

I have tried this patch with the latest CVS (Nov 13, 2009) and it breaks my TCP client connections using the netconn api.  After 1 or 2 connections, the netconn_connect fails to make a connection and either times out or sits indifinately in the tcpip_apimsg() function for the sys_arch_sem_wait() to occur.

I use freeRTOS, lwIP, PPP and the netconn api.

Dustin Stahlback <dstahlback>
Sun 01 Nov 2009 05:17:39 PM UTC, original submission:  

Due to our changes regarding tcp_recved/TCP_WND_UPDATE_THRESHOLD in 1.3.1, it can happen that, when in recv callback, first calling tcp_recved and then enqueueing new data, that 2 segments are sent: first a pure ACK, then the data segment.

This can be avoided by moving "tcp_input_pcb = NULL;" in tcp_input from directly after the call to tcp_process() to after the lines where TCP_EVENT_SENT/TCP_EVENT_RECV is called. Since tcp_output() is called thereafter, anyway, this makes sure segments are combined and it should have no negative side effect.

The only thing is we should consider to always call tcp_output after calling the callbacks (not only if err == ERR_OK).

Patch attached.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.


Attached Files
file #18971:  tcp_in.c.patch added by goldsimon (997B - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by dstahlback (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-12-02 goldsimon StatusNone => Fixed
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed
    2009-11-01 goldsimon Item GroupNone => Faulty Behaviour
        CategoryNone => TCP
    2009-11-01 goldsimon Attached File- => Added tcp_in.c.patch, #18971

    Back to the top

    Powered by Savane 3.5