ARP resolution not done from one end

[Nick Hibma]

> So, if you swap the MAC addresses of the client's virtual interfaces, and you
> don't send any packet FROM the client, then tinc will not learn of the new MAC
> addresses. If the server still remembers the old MAC addresses, and sends
> unicast packets via the wrong link, then the client's kernel will likely drop
> those packets, and there will be no response from the client to fix the
> situation.

The problem is not the roaming node (with the multiple tunnels), but the central node. I do actually manually do the ping when the tunnel comes up. Second the problem occurs after the MAC address expires, not after tunnel change (the 3G link is not operational at the moment).


> It could also be something else. Stateful firewall rules can expire their state
> after a while.

There are no firewalls in there doing anything, and certainly not with ARP requests (freebsd ipfw).

> Anyway, when it happens again, run tcpdump on the virtual
> interfaces (if possible on the server as well as on both of the client), and
> let tinc log what is happening (with tinc 1.0.x, use "tincd -n <netname> -kint"
> to temporarily raise the debug level, or with tinc 1.1pre7, just run "tinc -n
> <netname> log 5").

I see ping pong's.

Removing statements from the tinc config showed that after removing TunnelServer the ARP requests started coming through.

I don;t quite understand, but it does make some kind of sense.

Nick