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: TCPSeverity: 3 - Normal
Item Group: Change RequestStatus: Fixed
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned 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 Administrator
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
  • -unavailable- added by kieranm (Posted a comment)
  • -unavailable- added by goldsimon (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 24 Jan 2011 07:35:33 PM UTCgoldsimonStatusNone=>Fixed
      Assigned toNone=>goldsimon
      Open/ClosedOpen=>Closed
    Sat 20 Nov 2010 06:02:25 PM UTCgoldsimonPlanned Release=>1.4.1
    Sat 31 Jul 2010 06:10:06 AM UTCgoldsimonAttached File-=>Added refuse_data.patch, #21113

    Back to the top


    Powered by Savane 3.1-cleanup1