Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Same SEQ number but different ACKs

From: "Sheahan, John" <John.Sheahan@xxxxxxxxxxxxx>
Date: Sun, 13 Apr 2008 08:39:04 -0400
I thought I was on to something with the SEQ numbers and ACKs but I was wrong so I'm back to the quesion of "why is my proxy server sending a RST at the end of every HTTPS conversation from one server?".
 
I tried running this through Wireshark's Expert and it came up with no errors, that would be the first way to rule out that SEQ numbers or ACKs were out being incorrectly sent by the application, correct? If so, I probably should have done this prior to my first post :-)
 
I debugged my firewall and don't see any RSTs coming from my remote destination to my proxy, I only see the RSTs coming from my proxy to my client. I have sniffed other HTTPS conversations from other clients using the same Squid proxy but don't ever see any resets so I'm trying to figure out what is unique about these conversations. I also checked with the Squid forum and this is not any type of bug.
Is there anything else I could be checking using Wireshark that might help me find a problem?
 
Here is the a snippet of the conversation in text format:
 
thanks,
jack
 
Info                                                                                                                             Time
4694 > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1460                                            08:55:52.012000
http-alt > 4694 [SYN, ACK] Seq=0 Ack=1 Win=64860 Len=0 MSS=1380                         08:55:52.012000
4694 > http-alt [ACK] Seq=1 Ack=1 Win=65535 Len=0                                                   08:55:52.012000
CONNECT distribution-xml.booking.com:443 HTTP/1.1                                                    08:55:52.012999
http-alt > 4694 [ACK] Seq=1 Ack=176 Win=64685 Len=0                                                08:55:52.012999
HTTP/1.0 200 Connection established                                                                             08:55:52.101999
Client Hello                                                                                                                   08:55:52.103000
http-alt > 4694 [ACK] Seq=40 Ack=318 Win=64860 Len=0                                               08:55:52.109000
Server Hello, Certificate, Server Hello Done                                                                      08:55:52.188000
4694 > http-alt [ACK] Seq=318 Ack=1043 Win=64532 Len=0                                            08:55:52.188000
Client Key Exchange, Change Cipher Spec                                                                      08:55:52.570999
Encrypted Handshake Message                                                                                      08:55:52.572000
http-alt > 4694 [ACK] Seq=1043 Ack=522 Win=64860 Len=0                                             08:55:52.573000
Change Cipher Spec, Encrypted Handshake Message                                                       08:55:52.658000
Application Data                                                                                                             08:55:52.658999
http-alt > 4694 [ACK] Seq=1110 Ack=966 Win=64860 Len=0                                             08:55:52.753999
Application Data, Application Data                                                                                    08:55:52.798000
4694 > http-alt [ACK] Seq=966 Ack=1359 Win=65286 Len=0                                             08:55:52.798000
[TCP segment of a reassembled PDU]                                                                              08:55:52.814999
[TCP segment of a reassembled PDU]                                                                              08:55:52.875000
[TCP segment of a reassembled PDU]                                                                              08:55:52.875999
4694 > http-alt [ACK] Seq=966 Ack=4107 Win=65535 Len=0                                             08:55:52.875999
[TCP segment of a reassembled PDU]                                                                              08:55:52.875999
4694 > http-alt [ACK] Seq=966 Ack=6647 Win=65535 Len=0                                             08:55:52.875999
[TCP segment of a reassembled PDU]                                                                              08:55:52.951999
[TCP segment of a reassembled PDU]                                                                              08:55:52.951999
4694 > http-alt [ACK] Seq=966 Ack=8211 Win=65535 Len=0                                             08:55:52.951999
[TCP segment of a reassembled PDU]                                                                              08:55:52.951999
[TCP segment of a reassembled PDU]                                                                              08:55:52.951999
4694 > http-alt [ACK] Seq=966 Ack=10743 Win=65535 Len=0                                            08:55:52.951999
[TCP segment of a reassembled PDU]                                                                              08:55:52.951999
4694 > http-alt [ACK] Seq=966 Ack=12327 Win=65535 Len=0                                            08:55:52.951999
[TCP segment of a reassembled PDU]                                                                              08:55:52.965000
4694 > http-alt [ACK] Seq=966 Ack=14839 Win=65535 Len=0                                            08:55:52.965000
[TCP segment of a reassembled PDU]                                                                              08:55:53.027999
4694 > http-alt [ACK] Seq=966 Ack=16407 Win=64167 Len=0                                            08:55:53.027999
Application Data                                                                                                              08:55:53.029000
[TCP segment of a reassembled PDU]                                                                               08:55:53.029000
[TCP segment of a reassembled PDU]                                                                               08:55:53.030000
4694 > http-alt [ACK] Seq=966 Ack=19144 Win=64155 Len=0                                             08:55:53.030000
[TCP segment of a reassembled PDU]                                                                               08:55:53.042000
4694 > http-alt [ACK] Seq=966 Ack=21868 Win=64167 Len=0                                             08:55:53.042000
[TCP segment of a reassembled PDU]                                                                               08:55:53.042000
Application Data                                                                                                               08:55:53.042000
http-alt > 4694 [FIN, ACK] Seq=23503 Ack=966 Win=64860 Len=0                                      08:55:53.042000
4694 > http-alt [ACK] Seq=966 Ack=23503 Win=63900 Len=0                                             08:55:53.042000
4694 > http-alt [ACK] Seq=966 Ack=23504 Win=65462 Len=0                                             08:55:53.042000
Encrypted Alert                                                                                                                08:55:53.042000
4694 > http-alt [FIN, ACK] Seq=989 Ack=23503 Win=65535 Len=0                                      08:55:53.042000
http-alt > 4694 [RST] Seq=23504 Win=64860 Len=0                                                           08:55:53.042999
 
 
 
 


From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Barry Constantine
Sent: Saturday, April 12, 2008 9:03 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Same SEQ number but different ACKs

If I understand this correctly, then the client could send the same SEQ number if delayed acknowledgment kicks in (either every other segment to timer based).

 

In other words, the client has nothing to send out but the server is sending the client segments.  TCP provides for delayed acknowledgements so that the client would send out an ACK even if it had no data to send (which would account for the client’s SEQ value not increasing).

 

If I misunderstood the problem, then please let me know.

 

-Barry

 

 


From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sheahan, John
Sent: Saturday, April 12, 2008 9:44 AM
To: wireshark-users@xxxxxxxxxxxxx
Subject: [Wireshark-users] Same SEQ number but different ACKs

 

I'm troubleshooting a problem with a 443 connection through a Squid proxy server.

The communication actually goes through but we are seeing RSTs at the end of every conversation after the FIN coming from the proxy server.

After looking at the packets, in the middle of the conversation, I am seeing the client send two packets with the same SEQ number with two different ACK values, at that point, I get a FIN for the duplicate SEQ number yet my client continues to send several more packets with the same SEQ (same as before the FIN) with different ACK values.

It is at that point that the proxy server sends a RST but the ACK value is way too high to match any of the previous SEQ numbers sent by my client.

 

I can understand a retransmission but am I correct in my thinking that I should never have a duplicate SEQ number with a different ACK value?

 

thanks

 

jack