"Mode Switch" and "Tunnelserver Yes" cause unnecessary traffic to clients (proposed patch)

[ZioPRoTo (Saverio Proto)]

> Well, IndirectData will force data to go "by the server", as you mentioned in
> your original mail, but tinc on the server will still forward it to the
> destination. So it will not be a full mesh, but routed over your hub-and-spoke
> network.

Hello again :)

given that I'm fine with my patch I want to share with you the results
of some tests I have done using "Mode = switch"

I have done some debug, using the "GraphDumpFile = /tmp/graph.dot" I
was able to compare the topology that tincd was creating with the VPN
tunnels and the topology that my OLSR sees into the overlay. Also
sniffing around with tcpdump to understand how packets were going
around I found the following:

Looks like that most of the problems, comes from the handling of the
broadcast UDP packets that my overlay routing protocol writes on the
VPN links.

this packets are ethernet frames with destination ff:ff:ff:ff:ff:ff
(because mode = switch)

Without Forwarding statement in the config file (this means Forwarding
= internal by default) I have the tincd damons forwarding messages,
and so the overlay protocol sees the full mesh.

WIth "Forwarding = kernel" I have very strange behaviour. If a node
has more than 1 ConnectTo statement, all "ConnectTo" links are
established, but it keeps talking only on the link estabilished using
the first "ConnectTo" statement.

With Forwarding = off
Unicast packets are not forwarded, and this is okay.
But Broadcast packets forwarded and the overlay protocol sees a full mesh

Saverio