[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: smtpserver 2.99.43b still dying with SEGV




> >      Do you mean that the actively running SMTP server dies, or
> >      that the one that is doing  accept()-calls does die ?
> > 
> >      In latter case it manifests itself as SMTP not responding,
> >      but former can be anything..
> 
> SMTP port stops responding.  Currently running servers are going on, but
> no new connections are accepted.

	Umm...  Not ECONNREFUSED ?  That is, no immediate responce
	of the service being unavailable, rather just silence ?
	(No SIGSEGVs, nor cores either?)

	Most likely you have A LOT of embryonic sockets in your machine,
	and it can't/won't accept any more until it has room.

	$ netstat -n | grep SYN_RECV

	I just added/changed this at the  smtpserver/smtpserver.c:

	    /* Set the listen limit HIGH, there has been an active
	       denial-of-service attach where people send faked SYNs
	       to open a connection to system that does not want to
	       talk with us at all -- or whose traffic goes thru a
	       routeing black-hole.   The SYN_RECV-queue can grow also
	       due to routeing black-hole behind of which some poor
	       fellow is trying to get our attention, but our replies
	       do not reach back to him/her. */
	    /* Often the system enforces some upper bound for this
	       limit, and you can't exceed it -- but some new systems
	       allow rather high limits, lets try to get benefits from
	       it! */

	    if (listen(s, 2000) < 0) {
	      fprintf(stderr, "%s: listen(): %s\n",
		      progname, strerror(errno));
	      exit(1);
	    }

	Unless your SOMAXCONN limit is too low (original default
	(#define!) value was 5!) you may be able to keep your
	system going.

	(Have you heard of SYN-spoof attacks ?  This is about it!)

> --
> Eugene (at home because we have a holiday today:)

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