kernel panics in in_lltable_lookup (with INVARIANTS)

[Brian Somers]

Hi,

I've been working on a fix to address an issue that came up with
our update of openssh-5.  The 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().  Because it uses
pipe(), stdin is no longer bi-directional and cannot be used for both
input and output by a child process.  This 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().  I 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 expects
just one descriptor).  Although I'm happy with the patch and planned 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:
    in_lltable_lookup()
    llentry_update()
    flowtable_lookup()
    ip_output()
    ....

The panic is due to a KASSERT in in_lltable_lookup() that expects the
sockaddr to be AF_INET.  Number 18 is AF_LINK.

AFAICT this is happening while setting up a temporary route for the
first outbound packet.  I haven't been able to do much investigation
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.

-- 
Brian Somers                                          <brian at Awfulhak.org>
Don't _EVER_ lose your sense of humour !               <brian at FreeBSD.org>