arp_rtrequest() panich & patch for comments

[Bruce M Simpson]

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) == 0 &&
> +                   rt_mask(rt) != NULL &&
>                    SIN(rt_mask(rt))->sin_addr.s_addr != 0xffffffff)
>                        rt->rt_flags |= 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:
> 
> 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 
> 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().

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 167 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20041025/8e545425/attachment.bin