Date: Mon, 25 Oct 2004 19:12:18 +0300 From: Iasen Kostov <tbyte@OTEL.net> To: freebsd-net@freebsd.org Subject: arp_rtrequest() panich & patch for comments Message-ID: <417D25E2.1080309@OTEL.net>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?417D25E2.1080309>