From owner-freebsd-hackers Sun May 19 13:48:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA21948 for hackers-outgoing; Sun, 19 May 1996 13:48:25 -0700 (PDT) Received: from cygnus.ucdavis.edu (root@cygnus.ucdavis.edu [128.120.2.38]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA21932 for ; Sun, 19 May 1996 13:48:17 -0700 (PDT) Received: from localhost.ucdavis.edu (itchris@localhost.ucdavis.edu [127.0.0.1]) by cygnus.ucdavis.edu (8.6.12/8.6.12) with SMTP id NAA01659 for ; Sun, 19 May 1996 13:48:16 -0700 Message-Id: <199605192048.NAA01659@cygnus.ucdavis.edu> To: freebsd-hackers@freebsd.org Subject: routes, i'm stumped From: Chris Lambertus X-URL: http://cygnus.ucdavis.edu Date: Sun, 19 May 1996 13:48:15 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I've got a problem with routes on my slip server that's been plaguing me since I set it up. I've been through every reference I could find on the matter, and I'm completely stumped. I posted this to the freebsd newsgroups and once awhile ago to -users, but nobody had any ideas, so I'm hoping you guys will. My slip server is running 2.1-R. I use mgetty and sliplogin to assign routes and proxy arp entries. On the client side, I use startslip to dial in and establish the interface and routes on the client side. The client is running 2.0.5. The client side has two interfaces, ed0 and sl0. There are 5 machines on the ethernet segment that are being routed over the slip line. There are three problems, two of which appear to be related. 1. The slip server has a tendency to reboot once every 5-10 days. I cannot explain this (no hardware faults, no power failures that I can determine.) Is there a way I can debug this? I tried enabling kernel crash dumps, but it doesn't generate any when it crashes/reboots. Is there any other recourse for debugging this kind of thing? 2. Occasionally, the slip connection will die. The modems stay connected (two BOCA 28.8's) but the network connection stops functioning. To re-establish it, I have to HUP startslip and wait for it to redial. Once it redials, the connection comes back up. I suspect this might just be bad phone lines, but I would expect carrier to drop, which it doesn't. 3. (The worst one.) Every now and then, one of my routes dissapears. This is the one I'm dying to get fixed. On the slip server: # netstat -rn | egrep '226|227' 128.120.2.226 link#1 UHLW 3 349 128.120.2.226 0:40:5:19:fa:6d ULS2c 0 0 ed0 128.120.2.227 128.120.2.238 UGHS 3 24846 sl0 => 128.120.2.227 0:40:5:19:fa:6d ULS2c 0 0 ed0 # arp -a |egrep '226|227' punq.ucdavis.edu (128.120.2.226) at (incomplete) punq.ucdavis.edu (128.120.2.226) at 0:40:5:19:fa:6d permanent published mozzie.ucdavis.edu (128.120.2.227) at 0:40:5:19:fa:6d permanent published 128.120.2.238 is the slip client endpoint. Both 226 and 227 are machines behind the slip client on the ethernet. Notice how 226 on the slip *server* has become a link entry when it ought to be a static route entry. This is set up in slip.login as follows: /usr/sbin/arp -s 128.120.2.226 0:40:5:19:fa:6d pub /usr/sbin/arp -s 128.120.2.227 0:40:5:19:fa:6d pub /sbin/route add 128.120.2.226 128.120.2.238 /sbin/route add 128.120.2.227 128.120.2.238 I don't see why the 226 route would alter itself or what would cause it to be altered. Neither routed or gated are running on either machine. To fix this temporarily (until it vanishes again, maybe the next day) # route delete 128.120.2.226 delete host 128.120.2.226 # route delete 128.120.2.226 delete host 128.120.2.226 # route delete 128.120.2.226 writing to routing socket: No such process delete host 128.120.2.226: not in table # route add 128.120.2.226 128.120.2.238 add host 128.120.2.226: gateway 128.120.2.238 # arp -s 128.120.2.226 0:40:5:19:fa:6d pub # netstat -rn | egrep '226|227' 128.120.2.226 128.120.2.238 UGHS 0 3 sl0 128.120.2.226 0:40:5:19:fa:6d UHLS2 0 0 ed0 128.120.2.227 128.120.2.238 UGHS 3 28073 sl0 => 128.120.2.227 0:40:5:19:fa:6d ULS2c 0 0 ed0 So, that's my problem. Does anyone have any ideas why this is happening and what I can do to fix it? Thanks, -Chris -- Christopher M. Lambertus | cmlambertus@ucdavis.edu IR Distributed Systems Security | Office: (916) 754-9022 University of California | Fax: (916) 752-9154 Davis, California 95616 | Gabbpuy! 4400 forever!