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

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Sun 01 Nov 2009 05:17:39 PM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  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>
Group administrator
Wed 02 Dec 2009 09:15:15 AM UTC, comment #4: 

Sounds OK to me

Kieran Mansley <kieranm>
Group 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>
Group administrator
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

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>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    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 CategoryNone TCP
        Item GroupNone Faulty Behaviour
    2009-11-01 goldsimon Attached File- Added tcp_in.c.patch, #18971

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code