Hi, I am observing what appears to be a kernel problem related to making TCP connections. I am using nmap in connect scan mode for bulk scanning. Nmap 3.30, SuSE Linux kernel 2.4.21-199-default. Problems observed on both Intel and AMD systems - all fairly powerful (at least P3 1ghz, 384mb RAM) - using a variety of network cards (mostly Intel and 3COM). I noticed that nmap would sometimes miss ports that were open. Here is a trace of the problem happening: delores:/var/tcpdump # tcpdump -nvr dump.pcap5 'host 4.3.2.1 and port 80 and 51706' 12:33:14.470823 1.2.3.4.51706 > 4.3.2.1.80: S [tcp sum ok] 996359288:996359288(0) win 5840 <mss 1460,sackOK,timestamp 2228534500 0,nop,wscale 0> (DF) (ttl 64, id 57666, len 60) 12:33:14.488980 4.3.2.1.80 > 1.2.3.4.51706: S [tcp sum ok] 458278202:458278202(0) ack 996359289 win 5792 <mss 1460,sackOK,timestamp 3179934702 2228534500,nop,wscale 0> (DF) (ttl 52, id 0, len 60) 12:33:14.489072 1.2.3.4.51706 > 4.3.2.1.80: R [tcp sum ok] 996359289:996359289(0) win 0 (DF) (ttl 64, id 37620, len 40) 12:33:17.470637 1.2.3.4.51706 > 4.3.2.1.80: S [tcp sum ok] 996359288:996359288(0) win 5840 <mss 1460,sackOK,timestamp 2228537500 0,nop,wscale 0> (DF) (ttl 64, id 58213, len 60) 12:33:17.488135 4.3.2.1.80 > 1.2.3.4.51706: S [tcp sum ok] 461277814:461277814(0) ack 996359289 win 5792 <mss 1460,sackOK,timestamp 3179935002 2228537500,nop,wscale 0> (DF) (ttl 52, id 0, len 60) 12:33:17.488211 1.2.3.4.51706 > 4.3.2.1.80: R [tcp sum ok] 996359289:996359289(0) win 0 (DF) (ttl 64, id 38025, len 40) 12:33:23.470559 1.2.3.4.51706 > 4.3.2.1.80: S [tcp sum ok] 996359288:996359288(0) win 5840 <mss 1460,sackOK,timestamp 2228543500 0,nop,wscale 0> (DF) (ttl 64, id 59295, len 60) 12:33:23.489036 4.3.2.1.80 > 1.2.3.4.51706: S [tcp sum ok] 467277032:467277032(0) ack 996359289 win 5792 <mss 1460,sackOK,timestamp 3179935601 2228543500,nop,wscale 0> (DF) (ttl 52, id 0, len 60) 12:33:23.489097 1.2.3.4.51706 > 4.3.2.1.80: R [tcp sum ok] 996359289:996359289(0) win 0 (DF) (ttl 64, id 38732, len 40) The trace is selective output of tcpdump -nv, with the IP addresses anonymised. For comparison, here is the trace of a successful probe: 13:58:47.956914 1.2.3.4.43716 > 4.3.2.1.80: S 4204540905:4204540905(0) win 5840 <mss 1460,sackOK,timestamp 2954223574 0,nop,wscale 0> (DF) 13:58:47.957048 4.3.2.1.80 > 1.2.3.4.43716: S 3208365450:3208365450(0) ack 4204540906 win 5792 <mss 1460,sackOK,timestamp 295445296 2954223574,nop,wscale 0> (DF) 13:58:47.957070 1.2.3.4.43716 > 4.3.2.1.80: . ack 1 win 5840 <nop,nop,timestamp 2954223574 295445296> (DF) 13:58:47.957334 1.2.3.4.43716 > 4.3.2.1.80: R 1:1(0) ack 1 win 5840 <nop,nop,timestamp 2954223574 295445296> (DF) When nmap calls connect() to open the connection, the kernel sends a SYN. The remote host responds with a SYN-ACK. The kernel responds with an ACK to complete the threeway handshake. The kernel returns the socket connected; nmap immediately closes this so the kernel sends a RST. However, in the first trace the kernel is responding to the SYN-ACK incorrectly - by sending a RST instead of an ACK. The kernel then retries the SYN 3s later, then 6s after that. Each time the remote host correctly responds with SYN-ACK, but the kernel incorrectly responding with a RST. In some cases this has caused nmap to completely miss a port. However, nmap attempts several connect() calls so most the time the port is detected. It is difficult to see from the packet trace exactly how often this is happening. It is quite rare - maybe happens once for every 10 full 64k port scans. Has anyone seen this before? What can I do to stop it happening? Any help much appreciated, Dave __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
