LAN discovery issue

[Guus Sliepen]

On Sat, Jan 19, 2013 at 10:06:20PM +0100, Markus Teufelberger wrote:

> > What you can do is add another Address statement to hosts/Alpha on Gamma, with
> > Gamma's LAN IP address (just like you did with Beta). Make sure it is above the
> > other Address statement. That way, tinc will first try to connect via the LAN
> > IP. If that doesn't work, it will try resolving the DynDNS hostname.
> 
> Work perfectly on LAN now, BUT I seem now to have that problem the
> other way round:
> It seems to try quite often via the LAN IP and rather forwards the
> packets (even though I did remove the IndirectData stuff from all
> config files) though Alpha when connecting to the VPN from the
> internet from Gamma (who ConnetsTo Alpha) and pinging Beta... Even
> after a minute or so, the -d5 log just contains the following 5 lines:
> 
> Sending packet of 74 bytes to Alpha ([WAN-IP] port YYY)
> Received packet of 74 bytes from Alpha ([WAN-IP] port YYY)
> Writing packet of 74 bytes to Windows tap device
> Sending packet of 74 bytes to Beta (192.168.x.x port XXX)
> Packet for Beta (192.168.x.x port XXX) larger than minimum MTU, for
> warding via Alpha
> 
> Also in the beginning, there was the following error for some time
> periodically (went away though after half a minute or so):
> Error sending packet to Alpha ([WAN-IP] port YYY): (10014) The s
> ystem detected an invalid pointer address in attempting to use a pointer argumen
> t in a call.

Hm, half a minute corresponds with the maximum time PMTU discovery can take. So
somehow that fails (maybe it is indeed an invalid pointer, although it could
also be something completely different), and that means tinc thinks direct
communication with Alpha is not possible, so it will indeed forward packets via
another node.

> > Contrary to what the manual says, multicast IP traffic is also supported in
> > router mode, so you don't need to use switch mode for D-LAN.
> 
> I receive the following error with -d5 when running D-LAN (D-LAN is
> bound to the tinc interface):
> Cannot route packet from Gamma (MYSELF): unknown IPv4 destination
> address: 10.xx.xx.255

That's not a multicast address, but a broadcast address. I see in the FAQ on
D-LAN's website that they use 236.13.43.24 as the multicast address. My guess
is that those multicast packets are not being sent to tinc's interface by your
operating system. I have no idea how multicast actually works on Windows.

> My guess is that I somehow need to tell tinc that I am actually trying
> to run a 10.x.x.0/24 network, but on the other hand I only use static
> IPs (10.x.x.x/32) in my config files.

In this case it might indeed be better to run tinc in switch mode.

> That all aside, I ran into a different issue - from the manual:
> ‘ALRM’
> Forces tinc to try to connect to all uplinks immediately. Usually tinc
> attempts to do this itself, but increases the time it waits between
> the attempts each time it failed, and if tinc didn’t succeed to
> connect to an uplink the first time after it started, it defaults to
> the maximum time of 15 minutes.

Uhm, that is strange, it should not go to the maximum time immediately...  I
cannot reproduce this behaviour myself on Linux, but I'll try it on Windows
later.

> On a laptop it is (in my case) quite common that connecting to the
> wireless network takes a few seconds after booting - tinc seems to be
> faster and then is on a strike for 15 minutes (there's no way I know
> of to send a signal to a service on Windows). Please make that maximum
> value configurable or make it fail a bit more gracefully (first wait 2
> seconds, then 4, then 8 or whatever you do to increase the wait time)
> instead of going directly to the max. value.

You can change the maximum time with the MaxTimeout configuration variable.
Also, tinc 1.1 doesn't rely on signals anymore, you will be able to tell tinc
to immediately try reconnecting using the tincctl program.

> I tried to set up a
> backup program to run after boot - but then the tinc interface doesn't
> come up for 15 minutes after booting, which screws the whole process
> and confuses the hell out of that poor program too... ;-)

For now just add something like "MaxTimeout = 30" to tinc.conf :)

-- 
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: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20130120/495d9a5d/attachment.pgp>