Re: 2.99.48 smtpserver won't accept()?

[Matti Aarnio <mea@nic.funet.fi>]

> Now oddly enough, I saw this same symptom (sitting in an accept, but no
> connections get established) for the first time today, with zmailer 2.2e10,
> running on a SPARC 5 with SunOS 4.1.3_U1 -- the smtpserver binary hasn't
> changed, the OS hasn't changed, and everything had been working fine for 30+
> days before this.
> 
> Killing and restarting the smtpserver process made things work for about
> 15-20m, and then it happened again.
> 
> Rebooting the system, it hasn't happened in the 3 hours it has been up.
> 
> I'm a little worried about this...

	Doing  'netstat' would show you many sockets for the local
	smtp port in  SYN_RCVD state.  There is NOTHING we can do to
	it (in the user-space) at the older operating system releases.
	This situation is sometimes called "SYN-Attack" (when maliciously
	caused), or it can be caused by routing problem when our ACKs
	to the incoming SYNs don't reach the connect()or...

	Killing the smtpserver throws away those nascend sockets, and thus
	the new queue at the start of the new smtpserver will be clean..

	At SunOS 4.1.x the network code is deeply BSD, and I think you
	can find the routine responsible for SOMAXCON macro comparison,
	and change that fixed value in the binary...
	(See  G.R.Wright,W.R.Stevens: TCP/IP Illustrated, Volume2,
	 "The Implementation", page 455, "solisten() function")

	I did code  listen()  with HIGH limit, which can help you in
	similar case, provided the system does not limit the SO_MAXCON
	lower...  At lattest Linuxes (2.0.30+, 2.1.30+) the system is
	extremely SYN resilient, so appear to be with Solaris 2.5.1 (with
	patch), HP-UX 9.x/10.x (with patch), DEC UNIX 4.0, new FreeBSD/
	NetBSD codes, etc.

	Above I say 'resilient', I don't believe any of the methods is
	100% SYN-attack-proof, but presuming certain lowish maximum on
	how quickly the SYNs are coming, system can be made to tolerate
	it.  ( If any of them is proofed against 100Mbps ether full of
	fake SYNs, then it is SYN-attack-proof, but not before ;-) )

> 					\nick

	/Matti Aarnio <mea@nic.funet.fi>