buglwIP - A Lightweight TCP/IP stack - Bugs: bug #30577, tcp_input: don't discard ACK-only...


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

bug #30577: tcp_input: don't discard ACK-only packet after refusing 'refused_data' again

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Wed 28 Jul 2010 04:54:55 PM UTC  
Category:  TCP Severity:  3 - Normal
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Mon 24 Jan 2011 07:35:33 PM UTC, comment #4: 

Fixed that bug already, on 2011-11-23, which got lost during the savannah hack.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sat 31 Jul 2010 06:10:06 AM UTC, comment #3: 

In any case (pre- or post-1.4.0), here's a patch.

(file #21113)

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sat 31 Jul 2010 06:03:55 AM UTC, comment #2: 

Why not? I think the risk is low if we add an assert that refused_data==NULL some lines below after the if (recv_data != NULL).

On the other hand, I'm not really in a position to test this right now, so even a low risk might be to high...

Personally, I'm not using the refused_data feature anyway, but from Iordan's bug description, it's pretty unexpected behaviour that returning an error from the receive callback blocks ACKs, too.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Fri 30 Jul 2010 07:40:09 PM UTC, comment #1: 

Good idea.  Do you want this to go into 1.4.0?

Kieran Mansley <kieranm>
Project Member
Wed 28 Jul 2010 04:54:55 PM UTC, original submission:  

In tcp_input, after deciding for a pcb, we first check if that pcb has 'refused_data' and if so, we try to pass the data to its receive callback again.

If the callback rejects the data again, we drop the incoming packet and return.

I suggest to only drop the incoming packet if it contains data, i.e. to let ACK-only frames through and continue processing the packet as normal. This is because there should be no RECV-callback generated by this packet, and so we can safely leave the 'refused_data' as it is.

Does anyone see a pitfall here? Or any other reason this change wouldn't be a good idea?

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


Attached Files
file #21113:  refuse_data.patch added by goldsimon (1KiB - 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 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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-01-24 goldsimon StatusNone => Fixed
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed
    2010-11-20 goldsimon Planned Release => 1.4.1
    2010-07-31 goldsimon Attached File- => Added refuse_data.patch, #21113

    Back to the top

    Powered by Savane 3.5