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)