Wireshark-users: Re: [Wireshark-users] Same SEQ number but different ACKs
|
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 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 |
- Follow-Ups:
- Re: [Wireshark-users] Same SEQ number but different ACKs
- From: Sake Blok
- Re: [Wireshark-users] Same SEQ number but different ACKs
- References:
- [Wireshark-users] Same SEQ number but different ACKs
- From: Sheahan, John
- Re: [Wireshark-users] Same SEQ number but different ACKs
- From: Barry Constantine
- [Wireshark-users] Same SEQ number but different ACKs
- Prev by Date: [Wireshark-users] Installing Wireshark on OS X = clear as mud
- Next by Date: [Wireshark-users] Q: SSL error - ssl_decrypt_pre_master_secret wrong pre_master_secret length
- Previous by thread: Re: [Wireshark-users] Same SEQ number but different ACKs
- Next by thread: Re: [Wireshark-users] Same SEQ number but different ACKs
- Index(es):