On 03/01/18 00:30, David Gwynne wrote:
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.
yes, thanks -- it now works again with state-policy if-bound in pf.conf
and net.inet.ipip.allow=0
