From owner-freebsd-net@FreeBSD.ORG Fri Oct 19 03:00:08 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64BC216A417 for ; Fri, 19 Oct 2007 03:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 56B4B13C45A for ; Fri, 19 Oct 2007 03:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9J30706011867 for ; Fri, 19 Oct 2007 03:00:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9J307Lt011866; Fri, 19 Oct 2007 03:00:07 GMT (envelope-from gnats) Date: Fri, 19 Oct 2007 03:00:07 GMT Message-Id: <200710190300.l9J307Lt011866@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Peter Wemm Cc: Subject: Re: kern/116172 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Wemm List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 03:00:08 -0000 The following reply was made to PR kern/116172; it has been noted by GNATS. From: Peter Wemm To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/116172 Date: Thu, 18 Oct 2007 19:32:25 -0700 I've narrowed down the panic trigger. I have two userland processes doing a tun0 tunnel. The purpose is to do IPv6 encapsulated in UDP. The local end has an open ssh connection to the remote end. If I reboot at that instant, both the ssh and the tunnel driver receive a sigterm at the same time. The death of the tun0 driver causes the tun0 interface to be torn down and the routes cleaned up. At the same time, the death of the ssh process attempts to send a tcp6 FIN to be sent. This causes the panic described above. A simple workaround is to do a 'ssh -4' to the remote end rather than over the tunnel. This avoids the simultanious tun0 route teardown and the ssh teardown. It only seems to be a problem with ssh to the precise remote endpoint. ssh over the tunnel to other machines does not cause the panic when the machine is rebooted. Sample tun0 driver to trigger the panic: http://people.freebsd.org/~peter/qd_tun.c - quick & dirty tunnel :-) Ifconfig some ipv6 addresses to each end. ssh to the other end, reboot(8) locally, wait for the kaboom! -Peter