Tinc 1.0.17, switch mode and IPv6: set DecrementTTL = no

[Cédric Lemarchand]

Le 22/03/12 17:14, Guus Sliepen a écrit :
> On Thu, Mar 22, 2012 at 03:01:26PM +0100, Cédric Lemarchand wrote:
>
>>>> When i try to ping GATE from V1, i can see arp request crossing the VPN
>>>> (on both br0 interfaces), packet capture on GATE show the arp reply, but
>>>> this arp reply never come back on the bridge br0 of N2. (N2 is using
>>>> GATE has default gateway too)
>>> I think that is normal. The ARP request is a broadcast packet, so you should
>>> see that on all the interfaces. But the ARP reply is a unicast packet, so it is
>>> only sent to V1. The bridge on N1 should therefore not forward it to the VPN
>>> interface, so N2 will never see this ARP reply.
>> Ok, but the thing is dont anderstand is even if the ARP reply is
>> unicast, it should cross the VPN to go back to the machine that request
>> it ? (i use packet capture on promiscuous mode on the bridge, so i
>> should see it)
> I just tried to reproduce this and it appears the DecrementTTL option
> introduced in tinc 1.0.17, which defaults to "yes", causes neighbor discovery
> to fail. This might be the cause of your problems. So try to add this to your
> tinc.conf files:
>
> DecrementTTL = no
>
> And let me know of that solves the problem.
Guus, just tried with 1.0.17 and 1.1pre2, the same problem, unfortunately.

Can you confirm that on your side, with DecrementTTL off and 1.0.17, the
ethernet bridge work fine ?
Did you have any idea about different ways that could be explored to
find why it doesn't work ? I am going to think that the problem is not
related to tinc, in the sens that ethernet bridge is a current use of it.

Thx,

Cédric