locked
After pausing streams, ACKs are sent for segments that weren't received RRS feed

  • Question

  • I am trying to determine whether a known WFP-related bug is causing some HTTP downloads to become stuck due to incorrectly sent ACKs.

    Another thread ("clone-block-reinject on stream layer causes ack delays") suggests  "TcpAckFrequency=1" as a workaround but this didn't help.

    We use FWPS_STREAM_ACTION_DEFER and FwpsStreamContinue0. After the stream is paused/resumed, the machine ACKs segments which were not yet received. It never ACKs the server's last segments, and the stream becomes stuck.

    Outgoing packets:

    [ACK] Seq=102 Ack=1150481 Win=65700 Len=0
    [ACK] Seq=102 Ack=1151941 Win=65700 Len=0
    [ACK] Seq=102 Ack=1205961 Win=65700 Len=0
    [TCP ACKed lost segment] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
    [TCP Dup ACK 5861#1] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
    [TCP Dup ACK 5861#2] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0
    [TCP Dup ACK 5861#3] 49619 > http [ACK] Seq=102 Ack=1277501 Win=65700 Len=0

    Incoming packets (len, ack, seq):

    23414 102       1178221    [TCP Window Full] [TCP segment of a reassembled PDU]
    8814   102       1201581    [TCP Window Full] [TCP segment of a reassembled PDU]
    32174 102       1210341    [TCP segment of a reassembled PDU]
    29254 102       1242461    [TCP Window Full] [TCP segment of a reassembled PDU]
    1514   102       1205961    [TCP Retransmission] [TCP segment of a reassembled PDU]
    1514   102       1205961    [TCP Retransmission] [TCP segment of a reassembled PDU]

    (In summary, the client ACKs 1277501, while the server is only at SEQ 1205961. Full .pcap (1MB) is at http://patraulea.com/temp/wfp-lost-ack.pcap)

    This usually happens within the first 10MB of downloading, but only with linux peers (which split large (50KB) TCP segments into multiple IP fragments).

    My guess is that the ACK numbers are calculated as if the data (that's ignored due to pausing the stream) was received twice. If this is a known issue, is there any workaround ?

    Thursday, August 4, 2011 1:03 PM

All replies

  • IMHO there was a bug which was fixed in one of Windows updates. We had same problem with new installation of Win7, but it is gone after the update. Just patch your Windows installation.

    Saturday, November 19, 2011 7:26 AM
  • I'm watching the same problem in my WFP driver. After several FWPS_STREAM_ACTION_DEFER and FwpsStreamContinue0 on the same flow, I'm watching bad ACKs:

    2090 14.671493   192.168.8.134         192.168.8.5           TCP      60     h323hostcallsc > http [ACK] Seq=157 Ack=7121881 Win=65535 Len=0

    2091 14.671512   192.168.8.5           192.168.8.134         TCP      8814   [TCP segment of a reassembled PDU]

    2092 14.886388   192.168.8.5           192.168.8.134         TCP      1514   [TCP Retransmission] [TCP segment of a reassembled PDU]

    2093 14.903332   192.168.8.134         192.168.8.5           TCP      66     [TCP ACKed lost segment] h323hostcallsc > http [ACK] Seq=157 Ack=7142321 Win=65535 Len=0 SLE=7121881 SRE=7123341

    Frame 2093 acks 20440 bytes which have not been received yet. 

    Cross referencing with traces in my WFP driver, the last call to my callout before deferring the stream  received 10220 bytes then I decided to defer the stream; then, resuming the stream started with the ACK in Frame 2093 which acks the double of the bytes indicated in my callout, which makes me suppose (as Bogdan Harjoc) that there is a bug in WFP when calculating received data... 

    I'm testing in Windows 7 SP 1
    Thursday, June 7, 2012 7:10 PM
  • We are currently investigating this and will post back when we have any further information.

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Friday, June 8, 2012 4:52 AM
    Moderator
  • Are there any news on this issue? I see the same problem when my WFP filter driver is running - after a call to FwpsStreamContinue TCP/IP sends a wrong ACK packet, with Ack field incremented by the number of bytes in last already acked packet. 

    Here is the dump:

    441514    596.282243    192.168.137.2    192.168.137.3    TCP    1514    [TCP segment of a reassembled PDU]
    441515    596.282316    192.168.137.3    192.168.137.2    TCP    54    49572 > http [ACK] Seq=387 Ack=42511584 Win=73000 Len=0
    441516    596.282738    192.168.137.2    192.168.137.3    TCP    1514    [TCP segment of a reassembled PDU]
    441517    596.284404    192.168.137.2    192.168.137.3    TCP    1514    [TCP segment of a reassembled PDU]
    441518    596.284705    192.168.137.2    192.168.137.3    TCP    1514    [TCP segment of a reassembled PDU]
    441519    596.285005    192.168.137.2    192.168.137.3    TCP    946    [TCP segment of a reassembled PDU]
    441520    596.285379    192.168.137.2    192.168.137.3    TCP    1514    [TCP segment of a reassembled PDU]
    441521    596.285851    192.168.137.2    192.168.137.3    TCP    1514    [TCP segment of a reassembled PDU]
    441522    596.285922    192.168.137.3    192.168.137.2    TCP    54    [TCP ACKed lost segment] 49572 > http [ACK] Seq=387 Ack=42521236 Win=73000 Len=0

    42521236 - 42511584 = 9652. The number of received bytes between the ACKs is 8192. The difference is 1460, which is the number of bytes in packet 441514.

    FWPS_STREAM_ACTION_DEFER was returned somewhere between the ACKs, so apparently there is a bug here.

    Thursday, May 23, 2013 6:49 PM
  • I have the same problem as described here: http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/f97202f3-d388-4669-a932-7eaa824dfb57
    Saturday, May 25, 2013 7:13 AM
  • Is there any new about this issue? I am having a similar problem with Windows 8.

    Joe Field


    Joe Field

    Sunday, March 23, 2014 7:38 PM
  • Microsoft is currently working on a fix for this. The fix is under going testing. I'll try to post back with a location to obtain the fix when it is released.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Thursday, March 27, 2014 6:11 PM
    Moderator
  • Any word if the testing is complete?

    Thanks,

    Joe


    Joe Field

    Wednesday, May 7, 2014 8:46 PM
  • Any word if this testing is complete?

    Thanks


    Joe Field

    Wednesday, July 16, 2014 10:03 AM
  • We had same issue and reported it to MS last year. But because we cannot wait to fix, we used throttling by dropping ACK packets if necessary on TRANSPORT layer.

    It works at glance.

    Hope this helps to you get more functional driver..

    Tuesday, August 12, 2014 1:46 PM
  • Hi.

    We are facing the same problem. Is there any operating system update or fix regarding this issue?

    Thanks in advance,

    Javier Guerrero
    Tuesday, September 1, 2015 11:52 AM