From owner-freebsd-hackers Thu Sep 9 8: 9: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id CC87C15200; Thu, 9 Sep 1999 08:08:56 -0700 (PDT) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.7.3) id LAA07503; Thu, 9 Sep 1999 11:07:20 -0400 (envelope-from jared) Date: Thu, 9 Sep 1999 11:07:20 -0400 From: Jared Mauch To: Stas Kisel Cc: avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations Message-ID: <19990909110720.A6694@puck.nether.net> Mail-Followup-To: Stas Kisel , avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG References: <199909091015.UAA02113@cheops.anu.edu.au> <199909090945.NAA18133@sonet.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <199909090945.NAA18133@sonet.crimea.ua> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Sep 09, 1999 at 01:45:39PM +0400, Stas Kisel wrote: > > From: Darren Reed > > > The problem with this is the BSD TCP/IP implementation ACK's (or at least > > attempts to ACK) data as soon as it is received and it is a big no-no to > > discard queued data that has already been ACK'd. > > Probably it is not self-evident why we HAVE to drop this connection. > > It is evil connection. Good applications do read data from their sockets, > and evil ones do not. And ever if it is good, but silly or busy > application, good clients do not send so much data that application > can not process it. Am I wrong, there are any examples? (I have a program that is built to process this all, and works well on the non *bsd unicies, and has had a few problems on the *bsd based ones.. read on...) I posted a message on bugtraq related to this, and archive related mail to -current links are here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=340672+354590+/usr/local/www/db/text/1998/freebsd-current/19980524.freebsd-current http://www.freebsd.org/cgi/getmsg.cgi?fetch=246072+248435+/usr/local/www/db/text/1998/freebsd-current/19980524.freebsd-current Now the problems that I have are partially design issues in my program, and partially not. I am creating about 100 icmp sockets, and as they are created, allocate a very large SO_RCVBUF: (void)setsockopt(localstruct->icmp_s, SOL_SOCKET, SO_RCVBUF, (char *)&hold, sizeof(hold)); Where hold = (60*300) ie: hold 300 packets. Because I can be sending 100 icmp echo-requests out in a second, I can get at least that many replies back, if not more if some come out of order or delayed by more than 1 second. I also need to filter through all the icmp traffic that is coming to the system. (You can see my code, and comments are welcome to me directly, code available from ftp://puck.nether.net/pub/jared/sysmon* [if possible, my -current is in jared/beta/*, use that, but there have been little changes to that code currently]). I would get out of mbufs, increase maxusers. Either my code is less agressive than originally, or something has changed in some of the freebsd releases since then, even slightly to prevent this from currently happening. I'm not sure which. NetBSD also suffers from this problem, and is more evident than FreeBSD right now. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message