I'm having trouble with a particular server via HTTPS. It appears
that my local linux machines are sending incorrect ACK. However, I
don't have enough expertise to know for sure.
Using wireshark, the server sends:
Transmission Control Protocol, Src Port: https (443), Dst Port:
36015 (36015), Seq: 27658, Ack: 827, Len: 18
Local machine replies:
Transmission Control Protocol, Src Port: 36015 (36015), Dst Port:
https (443), Seq: 827, Ack: 27677, Len: 0
It appears to me that the ACK is off-by-one (should have been 27676).
The server replies again with retransmissions. This is with several
kernel versions on local machines, ranging from 2.6.31 to 2.6.38.
Can anyone shed insight into what's happening? This looks like a bug to me.
Thanks,
Gabriel
Le lundi 22 août 2011 à 10:34 -0500, Gabriel Beddingfield a écrit :
I'm having trouble with a particular server via HTTPS. It appears
that my local linux machines are sending incorrect ACK. However, I
don't have enough expertise to know for sure.
Using wireshark, the server sends:
Transmission Control Protocol, Src Port: https (443), Dst Port:
36015 (36015), Seq: 27658, Ack: 827, Len: 18
Local machine replies:
Transmission Control Protocol, Src Port: 36015 (36015), Dst Port:
https (443), Seq: 827, Ack: 27677, Len: 0
It appears to me that the ACK is off-by-one (should have been 27676).
The server replies again with retransmissions. This is with several
kernel versions on local machines, ranging from 2.6.31 to 2.6.38.
Can anyone shed insight into what's happening? This looks like a bug to me.
Not a bug if frame carried a FIN
18:32:16.177801 IP 10.150.51.213.52264 > 10.150.45.194.22: Flags [F.], seq 3312, ack 3241, win 412, length 0
18:32:16.178096 IP 10.150.45.194.22 > 10.150.51.213.52264: Flags [F.], seq 3241, ack 3313, win 203, length 0
18:32:16.256949 IP 10.150.51.213.52264 > 10.150.45.194.22: Flags [.], ack 3242, win 412, length 0
* Gabriel Beddingfield | 2011-08-22 10:34:14 [-0500]:
I'm having trouble with a particular server via HTTPS. It appears
that my local linux machines are sending incorrect ACK. However, I
don't have enough expertise to know for sure.
Using wireshark, the server sends:
Transmission Control Protocol, Src Port: https (443), Dst Port:
36015 (36015), Seq: 27658, Ack: 827, Len: 18
Local machine replies:
Transmission Control Protocol, Src Port: 36015 (36015), Dst Port:
https (443), Seq: 827, Ack: 27677, Len: 0
It appears to me that the ACK is off-by-one (should have been 27676).
No, it is absolutely correct: ACK -> last seen Seq plus one (27658 + 18 + 1):
RFC 793:
If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive. Once a connection is established this is always sent.
Cheers, Hagen
Le lundi 22 août 2011 à 13:05 -0500, Gabriel Beddingfield a écrit :
On Mon, Aug 22, 2011 at 12:19 PM, Daniel Baluta [off-list ref] wrote:
quoted
quoted
quoted
It appears to me that the ACK is off-by-one (should have been 27676).
The server replies again with retransmissions. This is with several
kernel versions on local machines, ranging from 2.6.31 to 2.6.38.
quoted
Not a bug if frame carried a FIN
The server packet had the FIN bit set.
then its fine.
quoted
Well then, why do retransmissions occur?
Gabriel could you post the full capture file?
Sure: http://gabe.is-a-geek.org/tmp/20110822-skyward-conversation-segment.tcpdump
I clipped the conversation to the vicinity of the problem.
This sounds as a TSO bug, maybe driver/NIC related
What is the NIC/driver used on your server ?
try "ethtool -K eth0 tso off" on the server
$ tcpdump -p -n -S -r 20110822-skyward-conversation-segment.tcpdump
reading from file 20110822-skyward-conversation-segment.tcpdump, link-type EN10MB (Ethernet)
Sorry we miss a few frames just before.
14:48:31.368344 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], seq 401237709:401239157, ack 1404739303, win 64334, options [nop,nop,TS val 1663311 ecr 3624365496], length 1448
14:48:31.368410 IP 192.168.1.25.36015 > 50.84.128.30.443: Flags [.], ack 401239157, win 52128, options [nop,nop,TS val 3624365515 ecr 1663311], length 0
14:48:31.368556 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], seq 401239157:401240605, ack 1404739303, win 64334, options [nop,nop,TS val 1663311 ecr 3624365496], length 1448
14:48:31.369019 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], seq 401240605:401242053, ack 1404739303, win 64334, options [nop,nop,TS val 1663311 ecr 3624365496], length 1448
14:48:31.369099 IP 192.168.1.25.36015 > 50.84.128.30.443: Flags [.], ack 401242053, win 57920, options [nop,nop,TS val 3624365515 ecr 1663311], length 0
14:48:31.369357 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], seq 401242053:401243501, ack 1404739303, win 64334, options [nop,nop,TS val 1663311 ecr 3624365496], length 1448
14:48:31.369412 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [FP.], seq 401243501:401243519, ack 1404739303, win 64334, options [nop,nop,TS val 1663311 ecr 3624365496], length 18
following frames acknowledge all data sent from server and FIN flag.
14:48:31.369442 IP 192.168.1.25.36015 > 50.84.128.30.443: Flags [.], ack 401243520, win 57920, options [nop,nop,TS val 3624365516 ecr 1663311], length 0
Up to there, its OK.
But following frame makes no sense : this data was already acknowledged
14:48:31.373447 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], seq 401236261:401237709, ack 1404739303, win 64334, options [nop,nop,TS val 1663311 ecr 3624365496], length 1448
14:48:31.373532 IP 192.168.1.25.36015 > 50.84.128.30.443: Flags [.], ack 401243520, win 57920, options [nop,nop,TS val 3624365520 ecr 1663311,nop,nop,sack 1 {401236261:401237709}], length 0
client timeouts :
14:48:31.458943 IP 192.168.1.25.36015 > 50.84.128.30.443: Flags [F.], seq 1404739303, ack 401243520, win 57920, options [nop,nop,TS val 3624365605 ecr 1663311], length 0
14:48:31.475204 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], ack 1404739304, win 64334, options [nop,nop,TS val 1663321 ecr 3624365605], length 0
14:48:31.475351 IP 50.84.128.30.443 > 192.168.1.25.36015: Flags [.], ack 1404739304, win 0, length 0
14:48:31.475395 IP 192.168.1.25.36015 > 50.84.128.30.443: Flags [R], seq 1404739304, win 0, length 0