On 9/26/18 9:57 PM, Martin Pieuchot wrote:
> On 26/09/18(Wed) 15:56, Élie Bouttier wrote:
>> On 9/26/18 12:42 PM, Martin Pieuchot wrote:
>>> Hello,
>>>
>>> On 26/09/18(Wed) 11:59, [email protected] wrote:
>>>>> Synopsis: Page fault in rt_setgwroute triggered by npppd under
>>>>> specific circumstances
>>>>> Category: kernel (networking)
>>>>> Environment:
>>>> System : OpenBSD 6.3
>>>> Details : OpenBSD 6.3 (GENERIC) #100: Sat Mar 24 14:17:45 MDT 2018
>>>>
>>>> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC
>>>>
>>>> Architecture: OpenBSD.amd64
>>>> Machine : amd64
>>>>> Description:
>>>> On client connection, npppd cause a panic. It seems the panic occurs
>>>> when the
>>>> selected address for the tun interface is already used on another
>>>> interface. For instance,
>>>> if I use 10.0.0.254/24 on a vlan interface, using 10.0.0.254 on tun0
>>>> trigger the panic.
>>>> Using 10.0.0.253 for tun0 do not trigger the panic.
>>>>
>>>>> How-To-Repeat:
>>>> - Configure an interface with 10.0.0.254/24 (in my case a vlan
>>>> interface)
>>>> - Configure npppd like this:
>>>>
>>>> ipcp interco {
>>>> pool-address 10.0.0.64-10.0.0.127 for static
>>>> dns-servers 10.0.0.254
>>>> allow-user-selected-address no
>>>> }
>>>> interface tun0 address 10.0.0.254 ipcp interco
>>>>
>>>> - Connect the L2TP client (in my case through IPsec)
>>>
>>> Could you include the output of "# route -n show -inet" before
>>> connecting the L2TP client in your next report?
>>
>> Please see at the end of the mail. The concurrent network is
>> 10.0.252.0/24, shared between vlan252 and tun0.
>>
>>>
>>> Does the diff below help? Even if it does, please insert the route(8)
>>> output.
>>
>> It help, no panic, and the following line in the logs:
>>
>> npppd[44212]: ppp id=2 layer=ipcp logtype=Opened ip=10.0.252.65
>> assignType=static
>> npppd[44212]: write() failed in in_route0 on RTM_ADD : No route to host
>>
>> And no route for the client so the connection is not working.
>>
>> I tried manually (without -ifp tun0, carp252 is prefered):
>>
>> # route add 10.0.252.65 10.0.252.254 -ifp tun0
>> add host 10.0.252.65: gateway 10.0.252.254: No route to host
>>
>> Without the patch, the same route command trigger the same page fault.
>
> Thanks the problem is that the current code assume that every RTF_LLINFO
> route is a cloned one, which is not always true. Diff below uses the
> correct check for this assertion, and I'd like to commit it before 6.4.
>
> Any ok?
>
> Now even if this will fix the reported panic, the logic could be
> improved. However I'm not sure if the complexity is worth it.
>
> Why are you using the same address on tun and carp?
No strong reason, saving one IP address... I tested, it failed, so I
reported it and I changed my tun address. I am okay with the limitation
of forbidding this kind of route.
Thanks for the fix.
>
> Index: net/route.c
> ===================================================================
> RCS file: /cvs/src/sys/net/route.c,v
> retrieving revision 1.377
> diff -u -p -r1.377 route.c
> --- net/route.c 11 Jul 2018 19:52:19 -0000 1.377
> +++ net/route.c 26 Sep 2018 19:56:47 -0000
> @@ -396,10 +396,11 @@ rt_setgwroute(struct rtentry *rt, u_int
> struct sockaddr_in6 sa_mask;
>
> /*
> - * If we found a non-L2 entry on a different interface
> - * there's nothing we can do.
> + * If we found a non cloned L2 entry on a different
> + * interface, don't try to find a corresponding gateway.
> */
> - if (!ISSET(nhrt->rt_flags, RTF_LLINFO)) {
> + if (!ISSET(nhrt->rt_flags, RTF_LLINFO) ||
> + !ISSET(nhrt->rt_flags, RTF_CLONED)) {
> rtfree(nhrt);
> return (EHOSTUNREACH);
> }
>
