Hi Ville,
> Yes, I'm wondering about that too. The function ip6_tnl_set_cap() in
> ip6_tunnel.c determines if the device is capable of transmitting (or
> receiving) data based on the tunnel endpoint addresses.
>
> Would you put some checks into that function and see what it is doing on
> your machines? Unfortunately I'm not able to recreate this problem.
on both machines:
ip6_tnl_set_cap entered: 21d 21d 0d
ip6_tnl_set_cap inside: 21d 21d 0d
ip6_tnl_set_cap final: 21d 21d 30000d
ip6_tnl_set_cap put
ip6_tnl_add_linklocal called
ip6_tnl_set_cap entered: 1d 1d 0d
ip6_tnl_set_cap inside: 1d 1d 0d
ip6_tnl_set_cap final: 1d 1d 0d
ip6_tnl_set_cap put
ltype / rtype / p->flags.
oops ignore the "d" at the end.
shall I printk laddr, raddr and the results
of ipv6_chk_addr as well?
the test was:
+ ip -6 addr add 4000::1 dev wlan0
+ ipv6tunnel add ip6sec0 remote fe80::209:5bff:fe2f:ea7e local
fe80::202:ddff:fe
32:6525 dev wlan0
+ ip link set ip6sec0 up
+ ip -6 addr ls dev ip6sec0
10: ip6sec0@wlan0: <POINTOPOINT,NOARP,UP> mtu 1460
inet6 fe80::202:ddff:fe32:6525/64 scope link
valid_lft forever preferred_lft forever
inet6 ff02::1/128 scope global
valid_lft forever preferred_lft forever
+ ipv6tunnel add ip6sec1 remote 4000::2 local 4000::1 dev wlan0
+ ip link set ip6sec1 up
+ ip -6 addr ls dev ip6sec1
11: ip6sec1@wlan0: <NOARP,UP> mtu 1460
inet6 fe80::202:ddff:fe32:6525/64 scope link
valid_lft forever preferred_lft forever
inet6 ff02::1/128 scope global
valid_lft forever preferred_lft forever
Regards, Andreas
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
