From owner-freebsd-net@FreeBSD.ORG Tue Oct 26 03:28:04 2004 Return-Path: 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 4BE7616A4CF for ; Tue, 26 Oct 2004 03:28:04 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 655E143D58 for ; Tue, 26 Oct 2004 03:28:03 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5B4A065218; Tue, 26 Oct 2004 04:28:01 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47817-02; Tue, 26 Oct 2004 04:28:00 +0100 (BST) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 0C91C651FC; Tue, 26 Oct 2004 04:28:00 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7107D61CB; Mon, 25 Oct 2004 20:27:47 -0700 (PDT) Date: Mon, 25 Oct 2004 20:27:47 -0700 From: Bruce M Simpson To: Iasen Kostov Message-ID: <20041026032747.GH706@empiric.icir.org> Mail-Followup-To: Iasen Kostov , freebsd-net@freebsd.org References: <417D25E2.1080309@OTEL.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3siQDZowHQqNOShm" Content-Disposition: inline In-Reply-To: <417D25E2.1080309@OTEL.net> cc: freebsd-net@freebsd.org Subject: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 03:28:04 -0000 --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Can you please contact me off-list with more information about your Zebra configuration? On Mon, Oct 25, 2004 at 07:12:18PM +0300, Iasen Kostov wrote: > if ((rt->rt_flags & RTF_HOST) =3D=3D 0 && > + rt_mask(rt) !=3D NULL && > SIN(rt_mask(rt))->sin_addr.s_addr !=3D 0xffffffff) > rt->rt_flags |=3D RTF_CLONING; Good catch. This can and should be committed; it's a common sense null pointer check. > arp_rtrequest: bad gateway 192.168.100.0 (!AF_LINK) > 192.168.100 0.0.0.0 U1 0 0 vlan5 > 192.168.96/20 link#6 UC 0 0 vlan5 192.168.100.0/24 is a subnet of 192.168.96/20. Was the /20 there before? The 1 flag is set in the case of the 192.168.100.0 route, so it is being added by Quagga/Zebra somehow, and doesn't have the WASCLONED flag set. Also, the LLINFO flag is not set. There's clearly an interaction going on here between a more specific non-cloning network route and a more general cloning network route. > possibly is not right. And if the interface tun0 exists > everything is as it should be: >=20 > 192.168.100 tun0 U1 0 0 tun0 This is the correct line that I'd expect for an interface route to a network, which has the PROTO1 flag set, and is not static, and has no link-layer information (is not an ARP entry). Zebra is trying to add the route when the interface doesn't exist. So the RTF_GATEWAY flag should be cleared (as per route(8)) and a sockaddr_dl containing *the name of the interface* should be sent in the rtmsg. From the looks of the Zebra code, it does this. However you should run route(8) in monitor mode and watch the routing socket to be absolutely sure. > but whatever is the case - user space program should not be able to=20 > panic the kernel so easy ... > I don't know where really the bug is - in arp_rtrequest() or somewhere=20 > in the pipe that at the end calls arp_rtrequest(). Trying to walk through the code, I don't see RTF_ANNOUNCE being set anywhere in the kernel so that part in arp_rtrequest() can probably be skipped. Back in userland, the quagga/zebra call graph looks like this: rt_socket.c:kernel_add_ipv4() rt_socket.c:kernel_rtm_ipv4(RTM_ADD, p, rib, AF_INET); rtm_write(...) Not knowing more about your Zebra config it's difficult to do more. It is more than likely that Zebra is passing the wrong interface index to its rtm_write() function and this results in the inconsistency you see. BMS --3siQDZowHQqNOShm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBfcQyueUpAYYNtTsRAqILAJ9pbA/n7qqYxJXfGP/+ffLtdySEWgCeNbq6 rH16nnA/DIKy3GRZn2YoFWo= =Levw -----END PGP SIGNATURE----- --3siQDZowHQqNOShm--