*BSD News Article 27899


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!gatech!news.byu.edu!news.mtholyoke.edu!nic.umass.edu!thor.cs.umass.edu!merlot!doyle
From: doyle@merlot.cs.umass.edu (Jim Doyle)
Newsgroups: comp.os.386bsd.questions
Subject: CSLIP garbage collection bug?  FreeBSD 1.0e
Date: 26 Feb 1994 18:07:08 GMT
Organization: CS Dept., Umass-Amherst
Lines: 24
Message-ID: <2ko34c$ebv@thor.cs.umass.edu>
Reply-To: doyle@cs.umass.edu
NNTP-Posting-Host: merlot
X-Newsreader: TIN [version 1.2 PL0]

I've experienced a repeatable bug with FreeBSD 1.0e CSLIP.

I keep a SLIP connection up for long periods of time, opening and closing
many connections.  After awhile, I an unable to completely build up any
new TCP sessions. UDP traffic will continue to work fine. In the case
where new TCP sessions get locked, I will get a single ACK back from a 
Telnet of FTP, but connection establishment will not proceed further than
that. The solution is to reboot the FreeBSD box, and all will work fine.


Interestingly enough, I've been able to connect this behavior in a 
weak way to the depth of the TCP header compression hash table.
In my /sys/net/slcompress.h I have MAX_STATES = 64 ; From carefully
examining my history buffer, I see that 64 rlogins/telnets/ftp's after
I type slattach work, but the 65'th TCP service was the one I recall failing.
Interesting.

If this problem has been solved, or if someone else is handling it, let me
know... Otherwise, I'll chalk this up on my forever growing to-do list..
It may just be a garbage collection problem in the header compression code.


-- Jim Doyle	(doyle@cs.umass.edu)