Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Aug 2009 22:41:34 -0700
From:      Brian Somers <brian@Awfulhak.org>
To:        Kip Macy <kmacy@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org, Brian Somers <brian@FreeBSD.org>
Subject:   Re: kernel panics in in_lltable_lookup (with INVARIANTS)
Message-ID:  <20090821224134.11d9a2a1@dev.lan.Awfulhak.org>
In-Reply-To: <20090821215503.3eec9a15@dev.lan.Awfulhak.org>
References:  <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers <brian@FreeBSD.org> wrote:
> On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy <kmacy@freebsd.org> 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
>=20
> Hi,
>=20
> 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.
[.....]
> 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.

I wasn't correct - the data *IS* being read out of the back of
the tunnel device.  When I send the ICMP, it goes into the tun
device and comes out the back end as an AF_LINK packet.  ppp
silently discards this (ironically I have a comment noting
that I should really track unidentified packet counts).

I'll try to figure out what in if_tun.c is corrupting the family next...

Cheers.

> > On Fri, Aug 21, 2009 at 16:43, Brian Somers<brian@freebsd.org> 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 ha=
ve 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 ex=
pects
> > > just one descriptor). =C2=A0Although I'm happy with the patch and pla=
nned 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 investiga=
tion
> > > 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                                          <brian@Awfulhak.org>
Don't _EVER_ lose your sense of humour !               <brian@FreeBSD.org>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090821224134.11d9a2a1>