From owner-freebsd-net@FreeBSD.ORG  Mon Oct 25 16:13:19 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 795A616A4CE
	for <freebsd-net@freebsd.org>; Mon, 25 Oct 2004 16:13:19 +0000 (GMT)
Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151])
	by mx1.FreeBSD.org (Postfix) with ESMTP id BA41043D1F
	for <freebsd-net@freebsd.org>; Mon, 25 Oct 2004 16:13:16 +0000 (GMT)
	(envelope-from tbyte@OTEL.net)
Received: from dragon.otel.net ([212.36.8.135])
	by mail.otel.net with esmtp (Exim 4.30; FreeBSD)
	id 1CM7T8-000Dqt-09
	for freebsd-net@freebsd.org; Mon, 25 Oct 2004 19:13:14 +0300
Message-ID: <417D25E2.1080309@OTEL.net>
Date: Mon, 25 Oct 2004 19:12:18 +0300
From: Iasen Kostov <tbyte@OTEL.net>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: arp_rtrequest() panich & patch for comments
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Oct 2004 16:13:19 -0000

The problem is that there is a route in zebra's conf like this "ip route 
192.168.100.0/24 tun0" and when zebra first starts there is still not 
tun0. In the moment of setting up the tun0 interface (creating or 
associating IP) it looks like zebra tries to add this route which until 
this moment is inactive. And then *POOF* kernel panic in arp_rtrequest() 
at 180.
This is the segment of code:

                if ((rt->rt_flags & RTF_HOST) == 0 &&
                    SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff)
                        rt->rt_flags |= RTF_CLONING;

I saw that rtrequest1() does checks for rt_mask(rt) != NULL, so why 
arp_rtrequest() does not ?
Then I've changed it like this:


                if ((rt->rt_flags & RTF_HOST) == 0 &&
+                   rt_mask(rt) != NULL &&
                    SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff)
                        rt->rt_flags |= RTF_CLONING;

and the panic disappeared but this is what the kernel complains in that 
case :

arp_rtrequest: bad gateway 192.168.100.0 (!AF_LINK)

and adds a nice route like this:

192.168.100        0.0.0.0               U1          0        0   vlan5

There is vlan5 and route :

192.168.96/20      link#6             UC          0        0  vlan5

so it clones it or ... I don't really know what's happening :) but 
possibly is not right. And if the interface tun0 exists
everything is as it should be:

192.168.100        tun0               U1          0        0   tun0

but whatever is the case - user space program should not be able to 
panic the kernel so easy ...
I don't know where really the bug is - in arp_rtrequest() or somewhere 
in the pipe that at the end calls arp_rtrequest().

    Regards.