On 11.07.2013 17:04, Andriy Gapon wrote:
on 11/07/2013 17:28 Andre Oppermann said the following:
Andriy for example would never have found out about this problem other
than receiving vague user complaints about aborted connection attempts.
Maybe after spending many hours searching for the cause he may have
interfered from endless scrolling in Wireshark that something wasn't
right and blame syncache first. Only later it would emerge that he's
either receiving too many connections or his application is too slow
dealing with incoming connections.
That's true, but OTOH there are many interesting network conditions like
excessive packet loss that we don't shout about. The stats are quietly gathered
and can be examined with netstat. If a system is properly monitored then such
counters are graphed and can trigger alarms. If the system just misbehaves then
an administrator can use netstat for inspection.
Spamming logs in the case of e.g. DDoS attack is not very helpful, IMO.
I agree with that.
I try to make the system behavior more transparent so that even "hidden"
problems
can be detected easily. This includes adding more of them, like excessive
packet
loss. This makes FreeBSD a more friendly platform for sysadmins whereas
previously
people may have quietly move on to some other OS due to such unspecific
complications.
Most of the TCP related debugging it is protected by net.inet.tcp.log_debug.
In this
case it's more complicated because the socket code where this happens is
protocol
agnostic and I can't bond it with TCP.
I'm currently looking into a) applying a rate limiter to the message (as
suggested
by Luigi); and b) add a per-socket accept queue overflow statistic that is
visible
via netstat. I'll post patches for testing when done.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
