OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: [Full-disclosure] Reverse engineering the Windows TCP stack

From: pretty vacant (optimisteurocompton.net)
Date: Thu Mar 31 2005 - 12:11:42 CST


FYI:

TcpMaxConnectRetransmissions
Key: Tcpip\Parameters
Value Type: REG_DWORD - Number
Valid Range: 0 - 0xFFFFFFFF
Default: 5
Description: This parameter determines the number of times that TCP
retransmits a connect request (SYN) before aborting the attempt. The
retransmission timeout is doubled with each successive retransmission in a
particular connect attempt. The initial timeout value is three seconds.

-----Original Message-----
From: full-disclosure-bounceslists.grok.org.uk
[mailto:full-disclosure-bounceslists.grok.org.uk] On Behalf Of Nicolas
RUFF (lists)
Sent: Thursday, March 31, 2005 1:03 PM
To: full-disclosurelists.grok.org.uk
Subject: Re: [Full-disclosure] Reverse engineering the Windows TCP stack

>>>Hey, I am looking for Windows TCP/IP stack information, I would like
>>>to know why it behaves inconsistently to SYN|FIN|URG|PSH!
> I'm curious about this one too...can you guys keep the replies on the
list?

Well, at least when you try to connect to a closed port, Windows retries
several times (SYN) even when RST has been received. My Linux don't.

-> "telnet <non firewalled ip> <closed port>" while running Ethereal.

However I am not sure whereas it is the TCP/IP stack or the Winsock layer
that induces this behaviour.

TCP/IP fingerprinting relies on such oddities, I guess a little Googling
would help.

Regards,
- Nicolas RUFF

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/