does this error message mean anything bad?
Aryeh M. Friedman
Hash: SHA1
Limiting closed port RST response from 266 to 200 packets/second.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHsZXvk8GFzCrQm4ARArl7AJ4lN1HiA+h7sndRfqxjRKnAQTxvyACeN4Iw
5BHupo2vMGWi9NkKCP/x4mM=
=FVIm
-----END PGP SIGNATURE-----
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Ivan Voras
> Limiting closed port RST response from 266 to 200 packets/second.
It usually means someone (on a fast or local network) is doing a
portscan or a similar activity on the machine. In itself, it's nothing
bad, but it depends on your opinion about portscans.
But it can also mean that a often-used service on the machine (like http
or a database server) is down and you're getting a lot of failed
connection requests from clients.
Pietro Cerutti
> Limiting closed port RST response from 266 to 200 packets/second.
In the average case, someone is doing a portscan against you. In the
worst case, they're trying to do a DOS attack.
I suggest that you set the following sysctl variables
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
and that you read the man page for blackhole(4).
P.S. this would better fit on freebsd-questions@
--
Pietro Cerutti
PGP Public Key:
http://gahr.ch/pgp
Primeroz lists
RST packets to send to clients when a connection to a port that is not
listening arrives.
it is probably because you are receiving a lot of requests for port not in
listen, i would investigate that.
just my 2c
On Feb 12, 2008 12:49 PM, Aryeh M. Friedman <aryeh.f...@gmail.com>
wrote:
John-Mark Gurney
> Limiting closed port RST response from 266 to 200 packets/second.
Since everyone else has thrown their two bits in, it could also mean
that you have a busy server, and that you are exceeding 200
connections/sec, and that this is limiting the number of connections
we fully close per second. If you are testing a web server over
gige w/ small files, you will usually run into this problem..
Upding the sysctl net.inet.icmp.icmplim will increase this limit.
Yes, I know it's not intuitive the ICMP limit is responsible for
TCP RST's, but that's the way it is...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Bernd Walter
> Aryeh M. Friedman wrote this message on Tue, Feb 12, 2008 at 07:49 -0500:
> > Limiting closed port RST response from 266 to 200 packets/second.
>
> Since everyone else has thrown their two bits in, it could also mean
> that you have a busy server, and that you are exceeding 200
> connections/sec, and that this is limiting the number of connections
> we fully close per second. If you are testing a web server over
> gige w/ small files, you will usually run into this problem..
>
> Upding the sysctl net.inet.icmp.icmplim will increase this limit.
> Yes, I know it's not intuitive the ICMP limit is responsible for
> TCP RST's, but that's the way it is...
This is a _closed_ port RST, so a response to a packet, which belong
to a non existing connection.
This usually happens because outdated packets reach you, or your system
isn't the same as the other sides expected (either your host crashed or
you got anothers systems dynamic IP).
Another reason for this to happen is because of bugs in the TCP code
of the _other_ side - IIRC windows has had such a bug many years ago.
There is no special reason to increase the icmp lim, because it is
just to play nice with the other side(s), which is doing something
questionable anyway, if you are seeing that much responses.
This is not limiting you to 200 connection/s in any way, it is just
triggered if things go wrong.
If you see this on a busy server, you are either hit by the windows
bug, or by a bad connection between you and the client(s).
--
B.Walter http://www.bwct.de http://www.fizon.de
be...@bwct.de in...@bwct.de sup...@fizon.de