[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2.99.48 smtpserver won't accept()?
> 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 ;-) )
/Matti Aarnio <firstname.lastname@example.org>