Date: Thu, 9 Sep 1999 13:54:22 -0400 From: Jared Mauch <jared@puck.Nether.net> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: Stas Kisel <stas@sonet.crimea.ua>, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations Message-ID: <19990909135422.C11644@puck.nether.net> In-Reply-To: <199909091015.UAA02113@cheops.anu.edu.au> References: <199909090802.MAA16555@sonet.crimea.ua> <199909091015.UAA02113@cheops.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 09, 1999 at 08:15:47PM +1000, Darren Reed wrote: > In some mail from Stas Kisel, sie said: > [...] > > IMHO it is a good idea to develop tcp_drain() from /sys/netinet/tcp_subr.c > > It should be quite intellectual to select a target - a process or a uid, > > which does not read properly from it's sockets, and has many data in mbufs. > > 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. Would it be possible to get it out of mbuf's before it's ack'ed, and send ack after that? This way you prevent it from having that problem. Also, I believe it would be suitable to drop udp/icmp stuff from buffers if there is a problem, as those are designed to handle loss properly, as tcp isn't. If I miss a dns response, or icmp response, I'm not gonna cry. But if tcp sessions all start catching resets, that would be a problem. - 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-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990909135422.C11644>