From owner-freebsd-hackers Thu Aug 28 20:38:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA08250 for hackers-outgoing; Thu, 28 Aug 1997 20:38:20 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA08245 for ; Thu, 28 Aug 1997 20:38:17 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.8.7/8.8.6) id WAA23954; Thu, 28 Aug 1997 22:37:58 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma023818; Thu, 28 Aug 97 22:37:07 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id WAA10128; Thu, 28 Aug 1997 22:37:06 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Thu, 28 Aug 1997 22:37:06 -0500 (CDT) From: Kyle Mestery To: Brian Somers cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Sig 12's with user PPP In-Reply-To: <199708282354.AAA03561@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 29 Aug 1997, Brian Somers wrote: > Sounds *really* like an installation thing. Can you remove the UID > bit on ppp and run it as root. You should get a core with the sig 12 > - it would be interesting to know what the syscall problem is. > Sure, I can try this, but this happens regardless of whether or not I run ppp as root or as another user. > The routing table thing also sounds like something's out of step. > Perhaps a "make world" followed by a kernel install then a reboot is > in order ? What sort of "screwing up" does your routing table > experience ? > My impression is that it would not be solved by a make world, because as I said this problem has followed me through make world build since early june or so. As far as the routing tables being messed up, normally ppp just adds a default route. But, when it gets "screwed up" it appears taht ppp is trying to add a separate route to every host it can, in other words this is what my routing table looks like: hope.winternet.com$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 204.246.71.1 UGSc 1 6 tun0 10.0.2/24 link#1 UC 0 0 10.0.2.18 0:0:c0:f2:16:9c UHLW 0 20 lo0 10.0.2.255 ff:ff:ff:ff:ff:ff UHLWb 1 326 ed0 127.0.0.1 127.0.0.1 UH 1 26 lo0 192.129.84 204.246.71.1 UGc 0 0 tun0 198.137.142 204.246.71.1 UGc 0 0 tun0 198.174.169 204.246.71.1 UGc 2 0 tun0 199.199.122 204.246.71.1 UGc 0 0 tun0 199.199.124/23 204.246.71.1 UGc 0 0 tun0 204.246.64 204.246.71.1 UGc 0 0 tun0 204.246.64.128 127.0.0.1 UH 0 0 lo0 204.246.66.1 204.246.71.1 UGH 0 0 tun0 204.246.66.4 204.246.71.1 UGH 0 0 tun0 204.246.66.6 204.246.71.1 UGH 0 0 tun0 204.246.66.8/30 204.246.71.1 UGc 0 0 tun0 204.246.66.13 204.246.71.1 UGH 0 0 tun0 204.246.66.16 204.246.71.1 UGH 0 0 tun0 204.246.66.19 204.246.71.1 UGH 0 0 tun0 204.246.66.20 204.246.71.1 UGH 0 0 tun0 204.246.66.23 204.246.71.1 UGH 0 0 tun0 204.246.66.24 204.246.71.1 UGH 0 0 tun0 204.246.66.26/31 204.246.71.1 UGc 0 0 tun0 204.246.66.29 204.246.71.1 UGH 0 0 tun0 204.246.71.1 204.246.64.128 UH 39 0 tun0 204.246.76 204.246.71.1 UGc 0 0 tun0 204.246.78 204.246.71.1 UGc 0 0 tun0 204.246.84 204.246.71.1 UGc 0 0 tun0 204.246.87 204.246.71.1 UGc 0 0 tun0 204.246.90 204.246.71.1 UGc 0 0 tun0 204.246.100 204.246.71.1 UGc 0 0 tun0 204.246.103 204.246.71.1 UGc 0 0 tun0 204.246.104 204.246.71.1 UGc 0 0 tun0 204.246.112 204.246.71.1 UGc 0 0 tun0 204.246.114 204.246.71.1 UGc 0 0 tun0 204.246.116 204.246.71.1 UGc 0 0 tun0 204.246.123 204.246.71.1 UGc 0 0 tun0 204.246.126 204.246.71.1 UGc 0 0 tun0 206.145.128/23 204.246.71.1 UGc 0 0 tun0 206.145.135 204.246.71.1 UGc 0 0 tun0 206.145.147 204.246.71.1 UGc 0 0 tun0 206.145.148 204.246.71.1 UGc 0 0 tun0 206.145.150 204.246.71.1 UGc 0 0 tun0 This seems rather large to me. I am running routed with -q. I am now thinking of trying gated. I am just wondering if anyone else is seeing these sig12s, and if not, then why I am the only one seeing them. Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com