Re: UDP_ENCAP_ESPINUDP_NON_IKE

[Ryota Ozaki <ozaki-r%iij.ad.jp@localhost>]

On Thu, May 31, 2018 at 6:46 AM Chuck Zmudzinski <frchuckz%gmail.com@localhost> wrote:
>
> Ryota,
>
> I discovered this crash on netbsd current kernels is triggered by a
> rarely encountered routing configuration for IPv6.
>
> Here are the results of decoding the backtrace when it crashes
> (if_mcast_op is there):
>
> address                            function            File:line number
>
> ?() at ffffffff80205845        breakpoint        ??:?
> ?() at ffffffff804ee4e8        vpanic src/sys/kern/subr_prf.c:343
> ?() at ffffffff805ec155        kern_assert        ??:?
> ?() at ffffffff8057ef93        if_mcast_op src/sys/net/if.c:3595
> (discriminator 1)
> ?() at ffffffff802ce97c        in6_addmulti src/sys/netinet6/mld6.c:747
> (discriminator 3)
> ?() at ffffffff802d333f        nd6_rtrequest src/sys/netinet6/nd6.c:1585
> ?() at ffffffff805af696        rtrequest1 src/sys/net/route.c:1292
> ?() at ffffffff805b2aac        route_output src/sys/net/rtsock.c:759
> ?() at ffffffff805b0c8a        route_send src/sys/net/rtsock.c:473
> ?() at ffffffff80520989        sosend src/sys/kern/uipc_socket.c:1075
> ?() at ffffffff80505e28        soo_write src/sys/kern/sys_socket.c:122
> ?() at ffffffff804fa433        dofilewrite src/sys/kern/sys_generic.c:350
> ?() at ffffffff804fa539        sys_write src/sys/kern/sys_generic.c:320
> ?() at ffffffff8020f2bc        sy_call src/sys/sys/syscallvar.h:66
>
> After further testing I discovered the crash does not occur unless IPv6
> routing to the VPN client is configured a certain way.
>
> After looking at this decoding of the backtrace which involves routing
> and IPv6, I learned the crash is triggered by the -proxy modifier to the
> route command I was using in the ipv6-up script. Keep in mind I am using
> a NetBSD 7 userland and the NetBSD 7 version of the route command. I do
> not know if current's version of the route command can also use the
> -proxy modifier.
>
> More details:
>
> A while ago I discovered IPv6 connectivity to the VPN client requires
> that a route be added to the peer in the ipv6-up script of pppd, which
> is called when ppp0 comes up after phase1 and phase2 are established if
> the +ipv6 option is set in /etc/ppp/options. So I included this line in
> my ipv6-up script (In ipv6-up, $4 is the local IPv6 address on the ppp
> link, $5 is the remote IPv6 address on the ppp link, and $1 is the ppp
> interface name):
>
> /sbin/route add -inet6 $5%$1 $4%$1 -interface -proxy
>
> This provided connectivity between the peers on the ppp link. I added
> the -proxy modifier hoping to get the VPN client appear to be on the
> link-local ethernet network (just as pppd's proxyarp option does this in
> IPv4, proxy ndp theoretically can do this in IPv6). Although the -proxy
> modifier to the route command did not work to provide proxy ndp for IPv6
> on NetBSD, nor did using the ndp proxy command, it did not cause a
> system crash on NetBSD 7 or 8 kernels, but this -proxy modifier is what
> triggers the crash on NetBSD current kernels. I did find a solution for
> proxy ndp on NetBSD 7, but it required a patch to the NetBSD 7 kernel
> and use of the -proxy modifier in the route command.
>
> When I do this instead in ipv6-up I do not see a crash:
>
> /sbin/route add -inet6 $5%$1 $4%$1 -interface
>
> Without the -proxy modifier to the route command, there is no crash and
> IPv4 connectivity for the VPN client works fine using the proxyarp
> option in pppd. For IPv6, I only have connectivity on the link-local ppp
> link, as expected when only using link-local addresses without proxy ndp.
>
> According to route's man page, the -proxy modifier sets the RTF_ANNOUNCE
> flag, and as far as I can tell from the web interface for route's man
> page -proxy is still valid for NetBSD 8.0, although maybe it is not
> actually available in NetBSD current now, in which case this crash would
> never be seen in ordinary systems using current's route command. But
> using NetBSD 7's route command with the -proxy modifier with a current
> kernel, you will see this crash.

Thank you for the detailed report.

RTF_ANNOUNCE for IPv6 should be still valid on NetBSD 8. I fixed the issue
in -current and will pull up it to NetBSD 8 soon.

The panic is triggered by an assertion that is too strict for typical kernel
configurations. I suppressed the assertion by default.

Thanks,
  ozaki-r