buglwIP - A Lightweight TCP/IP stack - Bugs: bug #44399, receiving TCP Ack packet with...

 
 

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

bug #44399: receiving TCP Ack packet with Window Update

Submitted by:  ran <rang>
Submitted on:  Sun 01 Mar 2015 02:55:57 PM UTC  
 
Category: TCPSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Invalid
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned Release: None
lwIP version: git head

Thu 12 Mar 2015 08:49:14 PM UTC, comment #4:

Right. And since from reading the original post, this bug report seems to come from reading (and possibly misunderstanding) the sources "only", I'm closing this as invalid.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 11 Mar 2015 10:05:27 PM UTC, comment #3:

Simon,

I did misread what OP said. I think because he said Wireshark marked the packet as a Window Update, I got confused thinking SEQ and ACK had not advanced.

As you've noted, if SEQ and ACK are advanced from the last packet received, then it's not a pure window update. Conditional checks 1 or 2 (in tcp_receive) should trigger and update the window

Joel Cunningham <jcunningham>
Project Member
Fri 06 Mar 2015 09:29:05 PM UTC, comment #2:

There might be a misunderstanding here between the OP and comment #1, although I don't fully understand the OP:

Re comment #1:
The OP says (interpreted): "if seq or ack are NOT identical the last received packet, the window is not updated".

Re OP:
I don't understand. Wireshark marks the packet as window update when seq and ack number are the same as the packet before. This is what we do in tcp_receive.
Why do you say that seq or ack are not identical to the last packet in your case? And if they are not identical, why would this be a window update?

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 02 Mar 2015 07:59:53 PM UTC, comment #1:

From tcp_receive():

/* Update window. */
if (TCP_SEQ_LT(pcb->snd_wl1, seqno) ||
(pcb->snd_wl1 == seqno && TCP_SEQ_LT(pcb->snd_wl2, ackno)) ||
(pcb->snd_wl2 == ackno && tcphdr->wnd > pcb->snd_wnd)) {
pcb->snd_wnd = SND_WND_SCALE(pcb, tcphdr->wnd);
...
}

The third OR clause should capture the case you're describing. send_wl1 and send_wl2 are the SEQ and ACK from the last ACK packet that updated the window. So if we receive a pure window update where SEQ and ACK are unchanged from the last packet that updated the window, then the window sizes are compared

Joel Cunningham <jcunningham>
Project Member
Sun 01 Mar 2015 02:55:57 PM UTC, original submission:

hi
We have been playing a bit with the liwp library and might have found a bug. When receiving an Ack TCP packet with the same seq and ack number as the packet before but with a different window (wireshark identifies it as an Update Window Packet).
In LWIP in tcp_in.c:tcp_receive we see that the code (head branch) checks if the seq and ack are identical to the last received packet. If not (that is our case) then there is only a print and the window size is not updated.
We believe that this might be a bug.
Thanks
Ran

ran <rang>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by goldsimon (Posted a comment)
  • -unavailable- added by jcunningham (Posted a comment)
  • -unavailable- added by rang (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 12 Mar 2015 08:49:14 PM UTCgoldsimonStatusWorks For Me=>Invalid
      Assigned toNone=>goldsimon
      Open/ClosedOpen=>Closed
    Fri 06 Mar 2015 09:29:05 PM UTCgoldsimonStatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1