Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Mar 1998 04:49:38 -0600 (CST)
From:      Kevin Day <toasty@home.dragondata.com>
To:        dg@root.com
Cc:        fenner@parc.xerox.com, freebsd-bugs@hub.freebsd.org
Subject:   Re: kern/6059: Packets from 1.1.1.1 can crash 2.2 server
Message-ID:  <199803201049.EAA04350@home.dragondata.com>
In-Reply-To: <199803200737.XAA16035@implode.root.com> from David Greenman at "Mar 19, 98 11:37:09 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> >The following reply was made to PR kern/6059; it has been noted by GNATS.
> >
> >From: Bill Fenner <fenner@parc.xerox.com>
> >To: FreeBSD-gnats-submit@freebsd.org
> >Cc: toasty@dragondata.com
> >Subject: Re: kern/6059: Packets from 1.1.1.1 can crash 2.2 server 
> >Date: Thu, 19 Mar 1998 23:17:13 PST
> >
> > Ok, I let the SYN attack run for 6 hours; at 30 packets per second,
> > that was somewhere in the neighborhood of 648,000 SYN packets.  No
> > messages, no crash.  The only indication that anything was going on was
> > that my firewall administrator yelled at me =)
> > 
> > Maybe if we can figure out how you produced the arpresolve error there'll
> > be some way to replicate this.
> 
>    It looks to me like the machine in question ran out of mbuf clusters and
> paniced due to one of the bugs related to that. I think all will be well if
> NMBCLUSTERS is increased.

I've got NMBCLUSTERS set to 10240..... Higher still?

I've got no idea what caused this.... I have a ep0 card, configured like
this:

ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 204.137.237.3 netmask 0xffffff00 broadcast 204.137.237.255
	inet 205.253.12.3 netmask 0xffffffff broadcast 205.253.12.3
	ether 00:20:af:3a:46:e7 

Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use     Netif Expire
default            204.137.237.254    UGSc      112    20659       ep0
127.0.0.1          127.0.0.1          UH          0     2666       lo0
204.137.237        link#2             UC          0        0 
204.137.237.1      0:20:af:1a:14:eb   UHLW        1     1651       ep0    865
204.137.237.2      0:80:19:35:c6:4b   UHLW        6   403798       ep0   1200
204.137.237.3      0:20:af:3a:46:e7   UHLW        3  1343069       lo0
204.137.237.8      0:40:5:41:d3:32    UHLW        4    20170       ep0    693
204.137.237.254    0:0:c:31:b9:e1     UHLW      113        1       ep0    670
205.253.12         link#2             UCSc        0        0 
205.253.12.3       0:20:af:3a:46:e7   UHLW        1   726508       lo0 =>
205.253.12.3/32    link#2             UC          0        0 


(the machine is talking to itself a lot through it's two interfaces... there
are two ircd's running on this machine, each bound to one IP address, but
they also are connected together)


In any case, it's not happening now, and I wasn't able to reproduce it
either....  I guess if it happens again, i'll try to get in there before it
dies and see what has happened to the routing table.

Thanks for your help. :)


Kevin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803201049.EAA04350>