[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>