Date: Fri, 14 Apr 2000 00:40:03 -0700 (PDT) From: Ruslan Ermilov <ru@ucb.crimea.ua> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/17963: NATD appears to memory leak when a connection fails from the internal network to the external network. Message-ID: <200004140740.AAA09680@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/17963; it has been noted by GNATS. From: Ruslan Ermilov <ru@ucb.crimea.ua> To: Brian Nelson <brian@pocketscience.com> Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: bin/17963: NATD appears to memory leak when a connection fails from the internal network to the external network. Date: Fri, 14 Apr 2000 10:33:22 +0300 On Thu, Apr 13, 2000 at 01:34:15PM -0700, Brian Nelson wrote: > Ruslan Ermilov wrote: > > > > On Wed, Apr 12, 2000 at 07:18:39PM -0700, brian@pocketscience.com wrote: > > > > > > In production, we are making several connection attempts to do AOL > > > polling. Some are getting a failure to connect (actually, a > > > significant number are). Since we have noticed this behavior (a bug > > > on our end), we have also noticed that natd memory leaks, actually > > > pretty significantly. > > > > > > We're pulling ~50k connections/hour. It takes ~16 hours for the > > > daemon to leak enough that the network dies on the machine, until > > > you restart natd. > > > > > Are these TCP connections? (I will assume that they are below). > > Are these connections to the same remote machine/port? > > Are these connections from the same local machine/port? > > Yes, I am sorry, they are TCP connections. > They are all connecting to americaonline.aol.com (this is DNS > load-balanced) port 5190 (aol in /etc/services) > The local port changes, since it's ~ 100 processes each on 7 internal > machines. > > > > > > >How-To-Repeat: > > > Set up natd. > > > > > > from an internal machine, make several network connections that get > > > dropped on the remote end (not denied, but connection timeouts) > > > > > It is unclear what do you mean. Do these connections get established, > > and then single-dropped by the remote end, or not established at all? > > In the first case, turning on and tuning a system-wide TCP keepalive > > on the client side might help. Do you have it enabled? What are the > > values of net.inet.tcp.*keep* MIB variables? > > They're never established. Theyfail to successfully connect. a tcpdump > shows a lot of syn's and very few fin's. The client machines are > Solaris, so I am not sure how to do any TCP tuning. > Probably, I have a solution for you, but I need to know some details. Who (in the normal circumstances) closes the connection (sends FIN)? Client or server? Also, I would like to take a look on a tcpdump(1) log of one of these failing connections (without your keep-state rule for ipfw(8)). The failing connection should be: client sends SYN and never gots neither RST nor SYN-ACK back from the server. Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age 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?200004140740.AAA09680>