Date: Mon, 25 Oct 2004 20:27:47 -0700 From: Bruce M Simpson <bms@spc.org> To: Iasen Kostov <tbyte@OTEL.net> Cc: freebsd-net@freebsd.org Subject: Re: arp_rtrequest() panich & patch for comments Message-ID: <20041026032747.GH706@empiric.icir.org> In-Reply-To: <417D25E2.1080309@OTEL.net> References: <417D25E2.1080309@OTEL.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041026032747.GH706>