Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Oct 2004 19:20:49 +0300
From:      Iasen Kostov <tbyte@OTEL.net>
To:        freebsd-net@freebsd.org
Subject:   Re: arp_rtrequest() panich & patch for comments
Message-ID:  <417D27E1.10709@OTEL.net>
In-Reply-To: <417D26F0.5060406@OTEL.net>
References:  <417D25E2.1080309@OTEL.net> <417D26F0.5060406@OTEL.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Iasen Kostov wrote:

> Iasen Kostov wrote:
>
>> 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.
>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>
> I forgot. This is "FreeBSD DraGoN.OTEL.net 5.3-STABLE FreeBSD 
> 5.3-STABLE #15: Thu Jan 17 21:22:51 EET 2002 
> root@LANGW4.OTEL.net:/usr/src/sys/i386/compile/DRAGON  i386"
> sorry fo that :(

I'll shot myself ... Real date is "Thu Oct 21 2004" (cvsup date)

>    Regards
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?417D27E1.10709>