> On 1 Mar 2018, at 02:22, Andreas Bartelt <o...@bartula.de> wrote: > > On 02/27/18 22:35, Pavel Korovin wrote: >> On 02/28, David Gwynne wrote: >>> what is the status of sysctl net.inet.ipip ? >> David, thank you! That was easy :) >> Sorry for the noise. >> $ sysctl net.inet.ipip.allow >> net.inet.ipip.allow=0 >> # sysctl -w net.inet.ipip.allow=1 >> net.inet.ipip.allow: 0 -> 1 >> $ ping6 www.google.com >> PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes >> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms >> 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms >> ^C > > I'm also observing a breakage of a previously working IPv6 tunnelbroker > config on current (problem introduced since at least Feb, 23rd). > > The combination of two things made it work again (or at least works around > the underlying problem): > 1) sysctl net.inet.ipip.allow=1 [not yet documented at > www.openbsd.org/faq/current.html] > 2) removing ``set state-policy if-bound'' from my pf.conf [which always > worked before with the same tunnelbroker setup] > > According to pflog(4), a ping6 to some destination now looks buggy to me: > - outgoing icmp6 echo request is only visible on gif(4) > - incoming icmp6 echo reply is only visible on the underlying physical > interface of gif(4) > which blocks the ping6 in the case of ``set state-policy if-bound''.
i found what i think is the problem. it turns out the net.inet.ipip.allow sysctl was a red herring. it controls the processing of ipip by the network stack, it is not related to whether gif should accept packets. the problem was i got the mapping of ip addresses in incoming packets to the addresses on the tunnels wrong. this should be fixed in src/sys/net/if_gif.c r1.112. sorry for the inconvenience. dlg