Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Two people are using different PCs behind the same NAT box. They are regularly accessing the same website, hosted elsewhere. Intermittently, one of them sees the website take several minutes to load. The other can still access the website at normal speed. This lasts until the PC is rebooted, then the speed returns to normal. This slowness can affect either of the two devices but (so far) never both of them together.

Running tcpdump on the web server confirms that for some reason linux is not sending SYN/ACK packets in response to the SYNs until exactly seven SYNs later.

The eighth SYN packet does not include a TCP Timestamp. Other connections from behind the same NAT box (from the other PC) are responded to immediately and the TCP Timestamp is present but far in advance of the timestamps on the problem PC. I'm guessing this is relevant.

Is this PAWS at work? If so, is there a workaround? If not, what might it be?

Here are examples. First, a slow connection.

14:08:07.030430 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098862 ecr 0,sackOK,eol], length 0
14:08:07.940504 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098871 ecr 0,sackOK,eol], length 0
14:08:08.939792 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098881 ecr 0,sackOK,eol], length 0
14:08:09.940510 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098891 ecr 0,sackOK,eol], length 0
14:08:10.942483 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098901 ecr 0,sackOK,eol], length 0
14:08:11.942386 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098911 ecr 0,sackOK,eol], length 0
14:08:13.942542 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755098931 ecr 0,sackOK,eol], length 0
14:08:17.954887 IP 79.97.132.108.56423 > DSQ4003-45.tagadab.com.www: Flags [S], seq 1211796088, win 65535, options [mss 1460,sackOK,eol], length 0
14:08:17.954902 IP DSQ4003-45.tagadab.com.www > 79.97.132.108.56423: Flags [S.], seq 1999044177, ack 1211796089, win 5840, options [mss 1460,nop,nop,sackOK], length 0

Here's another slow connection:

14:11:07.663535 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100668 ecr 0,sackOK,eol], length 0
14:11:08.634437 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100677 ecr 0,sackOK,eol], length 0
14:11:09.635522 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100687 ecr 0,sackOK,eol], length 0
14:11:10.635860 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100697 ecr 0,sackOK,eol], length 0
14:11:11.637469 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100707 ecr 0,sackOK,eol], length 0
14:11:12.637582 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100717 ecr 0,sackOK,eol], length 0
14:11:14.637423 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 755100737 ecr 0,sackOK,eol], length 0
14:11:18.639374 IP 79.97.132.108.56486 > DSQ4003-45.tagadab.com.www: Flags [S], seq 3598517192, win 65535, options [mss 1460,sackOK,eol], length 0
14:11:18.639386 IP DSQ4003-45.tagadab.com.www > 79.97.132.108.56486: Flags [S.], seq 559871738, ack 3598517193, win 5840, options [mss 1460,nop,nop,sackOK], length 0

Here's a normal connection from the same NAT box, different host, (note larger timestamp value despite being before both the other examples):

14:07:26.288656 IP 79.97.132.108.65146 > DSQ4003-45.tagadab.com.www: Flags [S], seq 4164516354, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 908816007 ecr 0,sackOK,eol], length 0
14:07:26.288669 IP DSQ4003-45.tagadab.com.www > 79.97.132.108.65146: Flags [S.], seq 1207614459, ack 4164516355, win 5792, options [mss 1460,sackOK,TS val 14867019 ecr 908816007,nop,wscale 9], length 0
share|improve this question

migrated from stackoverflow.com Mar 29 '11 at 20:23

This question came from our site for professional and enthusiast programmers.

    
Do both hosts have the same IP address? –  bmk Mar 29 '11 at 16:57
1  
@bmk A comment from the OP was lost (it was on another version of the post); I'm reposting it manually: "Er... they're behind the same NAT box so they present the same IP to the world. But obviously behind the NAT device they have different RFC 1918 addresses." –  Michael Mrozek Mar 29 '11 at 20:25

1 Answer 1

Try to disable window scaling as advised here: Why would a server not send a SYN/ACK packet in response to a SYN packet

sysctl net.ipv4.tcp_window_scaling
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.