Date: Tue, 25 Jan 2000 11:19:54 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Warner Losh <imp@village.org> Cc: geniusj <geniusj@cmgsccc.com>, security@FreeBSD.ORG Subject: tcp patch tests good (w/ test results) (was Re: Merged patches) Message-ID: <200001251919.LAA05907@apollo.backplane.com> References: <200001251733.JAA04770@apollo.backplane.com> <200001251637.JAA04226@harmony.village.org> <200001251736.KAA04666@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:You are right.... Uggg, the indenting there is somewhat less than
:optimal. Will have ot fix that later. However, here's the corrected
:patch.
:
:Warner
:
:Index: netinet/tcp_input.c
:===================================================================
:RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v
:retrieving revision 1.103
:...
I'm testing it... oh what fun! On a 100BaseTX switched network,
with a duel-cpu 450 MHz SMP box as the attacker and a UP build -current
box (450 MHz) as the victim (UP build so the idle times come out right):
attacker victim victim victim
ICMP_BANDLIM ICMP_BANDLIM TCP_RESTRICT_RST
output lim 100 output lim 10 enabled
(ICMP_BANDLIM off)
1600 pps 98% idle 98% idle 98% idle
6400 pps 95% idle 95% idle 95% idle
12800 pps 90% idle 90% idle 90% idle
34000 pps 74% idle 74% idle 76% idle
41000 pps 69% idle 70% idle 70% idle
58000 pps 57% idle 57% idle 58% idle
88000 pps 34% idle 34% idle 36% idle
96000 pps 28% idle 29% idle 30% idle
103000 pps 23% idle 23% idle 23% idle
When I did an SMP build for the victim, it stopped responding at around
99000 pps, and started responding again after I stopped the attack. Apart
from that the numbers were similar -- the SMP box was somewhat less
efficient for obvious reasons.
I can't shove out more then 103000 pps on my attack box. At 103000 pps
the network was pushing around 6.2 MBytes/sec. I've got to run so I
don't have time to attack from several sources at once.
In anycase, I think the patch can be committed. The rest of my network
was idle (no multicast bounce leakage) during the test. I leave it up
to Warner to decide whether to enable ICMP_BANDLIM in GENERIC by default
or not. After thinking about it some more, I think I *would* enable it
in GENERIC.
These boxes both have on-motherboard 'fxp' ethernets (Intel EtherExpress
Pro 10/100B).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001251919.LAA05907>