arp_rtrequest() panich & patch for comments

[Iasen Kostov]

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.