From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 22 05:23:07 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EA16106568B; Sat, 22 Aug 2009 05:23:07 +0000 (UTC) (envelope-from prvs=147868619d=brian@FreeBSD.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id B73338FC08; Sat, 22 Aug 2009 05:23:06 +0000 (UTC) Received: from pd7ml2no-ssvc.prod.shaw.ca ([10.0.153.162]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 21 Aug 2009 22:55:07 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=BN5Fd0iOSU8A:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=6I5d2MoRAAAA:8 a=MMwg4So0AAAA:8 a=IdckobKmQywhugN5PFQA:9 a=H-E4T0RX_QdEYwG9dNAA:7 a=OZVq9tP-p7W9Ef3SHkVHqKDqpjkA:4 a=SV7veod9ZcQA:10 a=WJ3hkfHDukgA:10 a=yMt3MqSJ3BES6okv:21 a=47XE9mHQPc2XRumx:21 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd7ml2no-dmz.prod.shaw.ca with ESMTP; 21 Aug 2009 22:55:07 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AF5DAC433AA_A8F7A27B; Sat, 22 Aug 2009 04:55:03 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id CFCCFC460F8_A8F7A24F; Sat, 22 Aug 2009 04:55:00 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n7M4t38I090440; Fri, 21 Aug 2009 21:55:03 -0700 (PDT) (envelope-from brian@FreeBSD.org) Date: Fri, 21 Aug 2009 21:55:03 -0700 From: Brian Somers To: Kip Macy Message-ID: <20090821215503.3eec9a15@dev.lan.Awfulhak.org> In-Reply-To: <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org Subject: Re: kernel panics in in_lltable_lookup (with INVARIANTS) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 05:23:07 -0000 On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > Try this: >=20 > Index: sys/net/flowtable.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/net/flowtable.c (revision 196382) > +++ sys/net/flowtable.c (working copy) > @@ -688,6 +688,12 @@ > struct rtentry *rt =3D ro->ro_rt; > struct ifnet *ifp =3D rt->rt_ifp; >=20 > + if (ifp->if_flags & IFF_POINTOPOINT) { > + RTFREE(rt); > + ro->ro_rt =3D NULL; > + return (ENOENT); > + } > + > if (rt->rt_flags & RTF_GATEWAY) > l3addr =3D rt->rt_gateway; > else >=20 > You'll need to apply this by hand as gmail munges the formatting. >=20 > -Kip Hi, That certainly stops the panic, however data routed to the tun interface doesn't come out the back end and data written to the back end doesn't come out the tun interface. After connecting a 7-stable and a -current box, I get this sending a ping packet from the stable box: -stable: TCP/IP: OUT ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84) Physical: write Physical: 7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75 ~=3D.......:..d= ..u Physical: 84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43 ...b.....c`...TC Physical: 01 00 70 7c 7e ..p|~ meaning that ppp sees the ICMP when it reads the back of the tun interface, and writes the encapsulated data to its physical link (the "other end"). -current: Physical: read Physical: 7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75 ~=3D.......:..d= ..u Physical: 84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43 ...b.....c`...TC Physical: 01 00 70 7c 7e ..p|~ TCP/IP: IN ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84) meaning that ppp reads data from the physical link, decapsulates it and writes an ICMP to the back of the tun interface. Then nothing (no ICMP reply). Sending an icmp from the -current box doesn't wake ppp at all. On the -stable box: brian@gw ~ $ ifconfig tun0 tun0: flags=3D8051 metric 0 mtu 1540 inet6 fe80::240:f4ff:feb1:1c85%tun0 prefixlen 64 scopeid 0x6=20 inet 172.16.1.22 --> 172.16.1.20 netmask 0xffffffff=20 Opened by PID 89468 brian@gw ~ $ route get 172.16.1.20 route to: 172.16.1.20 destination: 172.16.1.20 gateway: 172.16.1.22 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu ex= pire 0 0 0 0 0 0 1540 = 0=20 and on the -current box: brian@dev ~ $ ifconfig tun0 tun0: flags=3D8051 metric 0 mtu 1540 inet 172.16.1.20 --> 172.16.1.22 netmask 0xffffffff=20 inet6 fe80::240:f4ff:feb1:10da%tun0 prefixlen 64 scopeid 0x7=20 Opened by PID 1647 brian@dev ~ $ route get 172.16.1.22 route to: 172.16.1.22 destination: 172.16.1.22 gateway:=20 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1540 1 0=20 According to ``netstat -I tun0'', Opkts is increasing when I send from the -current box, although netstat -s doesn't seem to see any more icmps. Maybe this problem isn't a routing problem. I'll look into it further and figure out if the packet is getting to the tun driver and if so, what it thinks it's doing with it. Thanks. > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > Hi, > > > > I've been working on a fix to address an issue that came up with > > our update of openssh-5. =C2=A0The issue is that openssh-5 now uses > > pipe() to create stdin/stdout channels between sshd and the server > > side program where it used to use socketpair(). =C2=A0Because it uses > > pipe(), stdin is no longer bi-directional and cannot be used for both > > input and output by a child process. =C2=A0This breaks the use of ssh > > as a tunnel with ppp on either end (set device "!ssh -e none host > > ppp -direct label") > > > > I talked with des@ for a while and then with the openssh folks and > > have not been able to resolve the issues in openssh that made them > > choose to enforce the use of pipe() over socketpair(). =C2=A0I now have= a > > patch to ppp that makes ppp detect that it's connected via pipe() and > > causes it to use stdin for input and stdout for output (usually it expe= cts > > just one descriptor). =C2=A0Although I'm happy with the patch and plann= ed on > > requesting permission to commit, I've bumped into a show-stopper > > that seems unrelated, so I thought I'd ask here if anyone has seen > > this or has any suggestions as to what the problem might be. > > > > The issue.... > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > panic string is: sin_family 18 > > Stack trace starts: > > =C2=A0 =C2=A0in_lltable_lookup() > > =C2=A0 =C2=A0llentry_update() > > =C2=A0 =C2=A0flowtable_lookup() > > =C2=A0 =C2=A0ip_output() > > =C2=A0 =C2=A0.... > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > sockaddr to be AF_INET. =C2=A0Number 18 is AF_LINK. > > > > AFAICT this is happening while setting up a temporary route for the > > first outbound packet. =C2=A0I haven't been able to do much investigati= on > > yet due to other patches in my tree that seem to have broken all my > > kernel symbols, but once I get a clean rebuild I should be back in > > business. > > > > If anyone has any suggestions, I'm all ears! > > > > Cheers. --=20 Brian Somers Don't _EVER_ lose your sense of humour !