LAN discovery issue

[Rob Townley]

If for some reason, MaxTimeout does not work:

A win32 sleep command could also be used.
At cmd.exe, set /?
i believe set or choice can take input but times out after a specified
amount of time.
tinc-up could sleep for 30 seconds or so.


On Sun, Jan 20, 2013 at 9:39 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:

> 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>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20130123/ab7846c8/attachment.html>