Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uwm.edu!uwvax!appenzell.cs.wisc.edu!tim
From: tim@appenzell.cs.wisc.edu (Tim Theisen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: cslip crashing Sun 4/20 4.1.1
Message-ID: <1991Mar9.202345.16270@spool.cs.wisc.edu>
Date: 9 Mar 91 20:23:45 GMT
References: <8329@suned1.Nswses.Navy.MIL>
Sender: news@spool.cs.wisc.edu (The News)
Distribution: na
Organization: U of Wisconsin CS Dept
Lines: 62

In article <8329@suned1.Nswses.Navy.MIL> efb@slced1.nswses.navy.mil (Everett F Batey) writes:
>This evening I thought I had cslip ( UofT SLIP 4.0 with cslipbeta and the
>sunos4 fixes ) working .. got connected onto a remote VAX (+e?) .. slattach
>dev locip remip .. locally (Sun 4/20) .. slattach devc locip remip baud. 
>
>No errors upon kernel or slattach make .. double checked the three READMEs
>for UT, cslipbeta and sunos4.
>
>Mar  6 19:01:39 slced1 vmunix: SunOS Release 4.1 (SLCED-SL) #1: Wed Mar 6 
>18:48:11 PST 1991 .. new kernel booted
>
>Got the good slip0 starting IP IP .. baud .. finally was able to route add
>hisnet myip 1 .. even got ping and finally rsh running .. compatible compress,
>baud .. as the traffic increased .. couldn't find much evidence of what else
>may have been going on.  ALL at once with no visible degradation  ..
>
>WHAT IS THE diffs from the above mentioned release configs to make a bullet
>proof kernel for an SLC (4/20 Sun) with SunOS 4.1.1 ?  ( NO PPP not an option,
>really )  Thank you /Ev/
>
>two more reboots with NO clues .. 

OK, here is a clue.  I found the following bug when I ported cslipbeta to
Ultrix 4.0.  In if_sl.c, there is a spot where the code looks at the data
in the mbuf to do type of service queueing.  However, it just blindly looks
where it expects the data to be.  When IP fragmentation is occuring, the
IP header and data are in seperate mbufs.  The code may access a memory
location off the end of the mbuf.  On the Ultrix MIPS kernel, if you were
unlucky enough to have the mbuf against the top of kernel memory, the access
would generate a trap and the kernel panics.

Here is the fix I applied to cslipbeta.  This might be the cause to your
problem.  In any case, it would not hurt to apply the patch.

*** if_sl.c.old	Sat Mar  9 14:09:12 1991
--- if_sl.c	Sat Mar  9 14:11:35 1991
***************
*** 456,462 ****
  	}
  	ifq = &ifp->if_snd;
  	if ((ip = mtod(m, struct ip *))->ip_p == IPPROTO_TCP) {
! 		register int p = ((int *)ip)[ip->ip_hl];
  
  		if (INTERACTIVE(p & 0xffff) || INTERACTIVE(p >> 16)) {
  			ifq = &sc->sc_fastq;
--- 456,464 ----
  	}
  	ifq = &ifp->if_snd;
  	if ((ip = mtod(m, struct ip *))->ip_p == IPPROTO_TCP) {
! 		register int p = -1;
! 		if (m->m_len > sizeof(struct ip))
! 			p = ((int *)ip)[ip->ip_hl];
  
  		if (INTERACTIVE(p & 0xffff) || INTERACTIVE(p >> 16)) {
  			ifq = &sc->sc_fastq;

Hope this solves your problem,  ...Tim
-- 
Tim Theisen             Department of Computer Sciences
Systems Programmer      University of Wisconsin-Madison
tim@cs.wisc.edu         1210 West Dayton Street
(608)262-0438           Madison, WI   53706