RE: -sT on windows

["Rob Nicholls" <robert () everythingeverything co uk>]

To clarify, I also get the 

CONN (0.2140s) TCP localhost > xxx.xxx.xxx.xxx:443 => Unknown error

style messages in 4.20 (and 4.11, and even back on 3.93; 3.81 crashes on the
test machine I'm using). What I meant in my observation was nmap only
started crashing in 4.22SOC6 (i.e. new behaviour since SOC5).

I must admit, up until today I thought that the "Unknown error" was probably
related to the "TCP CHECKSUM INCORRECT" warning that I also saw in
Wireshark. As nmap was correctly determining open ports (and no longer
crashing), and Wireshark suggested that the checksum error might be caused
by TCP checksum offloading (the network card uses the default setting of
TCP/UDP Checksum Offload (IPv4) - Tx Enabled), I wasn't too worried.
However, after disabling checksum offloading, I still see the "Unknown
error".

I'm assuming David's right about the unhandled error code, and I agree with
jah that it's not a showstopper. It's probably been around for at least 2
years, I'm sure it can wait until sometime after Tuesday to be "fixed" ;)


Rob


-----Original Message-----
From: jah [mailto:jah () zadkiel plus com] 
Sent: 09 December 2007 03:57
To: nmap-dev () insecure org
Subject: Re: -sT on windows



David Fifield wrote:
> On Sun, Dec 09, 2007 at 03:16:35AM +0000, jah wrote:
>   
> > As to the Unknown Error:
> > This seems to refer to errbuf in PacketTrace::traceConnect in
tcpip.cc:771
> > Does anyone have any idea what could be wrong?
> > The error occurs in 4.20 too, so it's not a recently introduced bug.
> > Whatever it is prevents further packet tracing.
> >     
>
> That's because Windows returns an unhandled error code, WSAEWOULDBLOCK,
> which is not really an error but means "operation in progress." See
> http://seclists.org/nmap-dev/2007/q3/0417.html. It probably ought to be
> changed some time.
>
>
>   
Aye, it's not a showstopper, but it reduces the usefulness of packet 
tracing with connect scans on windows.
And it definitely does occur in 4.20 which is interesting given Robs 
observation (http://seclists.org/nmap-dev/2007/q3/0410.html)
"Running the exact same command with nmap 4.11, 4.21-A1, 4.22SOC2, 
4.22SOC3, 4.22SOC5 appears to work fine. This seems to have started with 
4.22SOC6."


jah

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org