> On 1 Mar 2018, at 02:22, Andreas Bartelt <obsd@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
No comments:
Post a Comment