tinc devel - Apr 2015 - Strange tinc behavior on OSX Yosemite

Hi,

I have already working set of tinc nodes and tried to add one more machine,
mac mini with osx yosemite onboard.
Tincd starts and connects to other nodes as supposed but I can't connect to
mini from any of other nodes. When I try to use ssh the following lines
appears repeatedly in mini's logs along with the regular logs about making
connections and MTU probes:
> Got PACKET from gullinbursti (<white_ip> port 766): 17 78
> Received packet of 78 bytes from gullinbursti (<white_ip> port 766)
> Writing packet of 78 bytes to Generic BSD tap device
When I try to ping:
> Got PACKET from gullinbursti (<white_ip> port 766): 17 98
> Received packet of 98 bytes from gullinbursti (<white_ip> port 766)
> Writing packet of 98 bytes to Generic BSD tap device
But once I send any packet from the mini through the VPN (like ping or tcp
connect attempt to any otner node) everything just starts to work as
intended.

Looks like some issue in tuntaposx that prevents the interface from work
until a packet is sent to it.

I use tinc-1.0.21 and the following config:
> ConnectTo <host0>
> ConnectTo <host1>
> ConnectTo <host2>
> ConnectTo <host3>
>
> GraphDumpFile = /tmp/tinc-pac.graph
> Name = macmini
> Subnet = 10.21.1.16/32
> Port 766
> DecrementTTL = yes
> LocalDiscovery = yes
>
> Device = /dev/tap1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150406/bd701e61/attachment.html>

On 6 April 2015 at 15:56, Vladimir "Equidamoid" Shapranov
<equidamoid at gmail.com> wrote:
> Looks like some issue in tuntaposx that prevents the interface from work
> until a packet is sent to it.
Nope. The issue is that tinc is currently not smart enough to directly
read the MAC address of the TAP device for BSD-style devices (of which
tuntaposx is one). Therefore you need to send at least one packet
through it so that tinc can discover the device's own MAC address
through the source address of the packet you just sent. If you don't,
then tinc doesn't know which MAC address to use as the destination in
Ethernet headers for incoming packets, and is therefore unable to
receive them.

Specifically, you're hitting this issue because you're using tinc in
router (IP) mode but with a TAP (Ethernet) device, which is a special
configuration in which tinc has to forge Ethernet headers. If you
switch to a TUN device, the problem will go away as TUN devices are L3
(IP) and therefore don't use Ethernet headers - the only downside is
that you probably won't be able to use broadcasts (on Linux at least -
maybe Mac OS X can send/receive broadcasts on L3 devices). If you use
"switch" mode instead, that works too, but then you will have to
reconfigure your entire network.

tinc on Linux had the same issue until
https://github.com/gsliepen/tinc/commit/790b107f668a886c3b335e68b9440ef5152a2844
- however I did not write a fix for BSD devices, since I'm not sure
how to get the MAC address for these. I'm not even sure there's an
easy way to do that - tuntaposx doesn't seem to provide one.

If using TUN or "switch" mode is not possible for you, here's a
workaround: add some command to your tinc-up script that simply sends
one packet (e.g. ping) - it doesn't matter if the other side doesn't
respond - so that tinc can quickly learn the address.

On Mon, Apr 06, 2015 at 04:52:44PM +0100, Etienne Dechamps wrote:
> [...] If you
> switch to a TUN device, the problem will go away as TUN devices are L3
> (IP) and therefore don't use Ethernet headers - the only downside is
> that you probably won't be able to use broadcasts (on Linux at least -
> maybe Mac OS X can send/receive broadcasts on L3 devices).
Linux can send/receive broadcast packets on L3 interfaces just fine.
However, the few programs that do want to send broadcasts on all
interfaces, like avahi, usually ignore point-to-point interfaces.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150406/2e40c3f7/attachment.sig>