If for some reason, MaxTimeout does not work:<br><br>A win32 sleep command could also be used.  <br>At cmd.exe, set /? <br>i believe set or choice can take input but times out after a specified amount of time. <br>tinc-up could sleep for 30 seconds or so.  <br>
<br><br><div class="gmail_quote">On Sun, Jan 20, 2013 at 9:39 AM, Guus Sliepen <span dir="ltr"><<a href="mailto:guus@tinc-vpn.org" target="_blank">guus@tinc-vpn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Sat, Jan 19, 2013 at 10:06:20PM +0100, Markus Teufelberger wrote:<br>
<br>
> > What you can do is add another Address statement to hosts/Alpha on Gamma, with<br>
> > Gamma's LAN IP address (just like you did with Beta). Make sure it is above the<br>
> > other Address statement. That way, tinc will first try to connect via the LAN<br>
> > IP. If that doesn't work, it will try resolving the DynDNS hostname.<br>
><br>
> Work perfectly on LAN now, BUT I seem now to have that problem the<br>
> other way round:<br>
> It seems to try quite often via the LAN IP and rather forwards the<br>
> packets (even though I did remove the IndirectData stuff from all<br>
> config files) though Alpha when connecting to the VPN from the<br>
> internet from Gamma (who ConnetsTo Alpha) and pinging Beta... Even<br>
> after a minute or so, the -d5 log just contains the following 5 lines:<br>
><br>
> Sending packet of 74 bytes to Alpha ([WAN-IP] port YYY)<br>
> Received packet of 74 bytes from Alpha ([WAN-IP] port YYY)<br>
> Writing packet of 74 bytes to Windows tap device<br>
> Sending packet of 74 bytes to Beta (192.168.x.x port XXX)<br>
> Packet for Beta (192.168.x.x port XXX) larger than minimum MTU, for<br>
> warding via Alpha<br>
><br>
> Also in the beginning, there was the following error for some time<br>
> periodically (went away though after half a minute or so):<br>
> Error sending packet to Alpha ([WAN-IP] port YYY): (10014) The s<br>
> ystem detected an invalid pointer address in attempting to use a pointer argumen<br>
> t in a call.<br>
<br>
</div>Hm, half a minute corresponds with the maximum time PMTU discovery can take. So<br>
somehow that fails (maybe it is indeed an invalid pointer, although it could<br>
also be something completely different), and that means tinc thinks direct<br>
communication with Alpha is not possible, so it will indeed forward packets via<br>
another node.<br>
<div class="im"><br>
> > Contrary to what the manual says, multicast IP traffic is also supported in<br>
> > router mode, so you don't need to use switch mode for D-LAN.<br>
><br>
> I receive the following error with -d5 when running D-LAN (D-LAN is<br>
> bound to the tinc interface):<br>
> Cannot route packet from Gamma (MYSELF): unknown IPv4 destination<br>
> address: 10.xx.xx.255<br>
<br>
</div>That's not a multicast address, but a broadcast address. I see in the FAQ on<br>
D-LAN's website that they use 236.13.43.24 as the multicast address. My guess<br>
is that those multicast packets are not being sent to tinc's interface by your<br>
operating system. I have no idea how multicast actually works on Windows.<br>
<div class="im"><br>
> My guess is that I somehow need to tell tinc that I am actually trying<br>
> to run a 10.x.x.0/24 network, but on the other hand I only use static<br>
> IPs (10.x.x.x/32) in my config files.<br>
<br>
</div>In this case it might indeed be better to run tinc in switch mode.<br>
<div class="im"><br>
> That all aside, I ran into a different issue - from the manual:<br>
> ‘ALRM’<br>
> Forces tinc to try to connect to all uplinks immediately. Usually tinc<br>
> attempts to do this itself, but increases the time it waits between<br>
> the attempts each time it failed, and if tinc didn’t succeed to<br>
> connect to an uplink the first time after it started, it defaults to<br>
> the maximum time of 15 minutes.<br>
<br>
</div>Uhm, that is strange, it should not go to the maximum time immediately...  I<br>
cannot reproduce this behaviour myself on Linux, but I'll try it on Windows<br>
later.<br>
<div class="im"><br>
> On a laptop it is (in my case) quite common that connecting to the<br>
> wireless network takes a few seconds after booting - tinc seems to be<br>
> faster and then is on a strike for 15 minutes (there's no way I know<br>
> of to send a signal to a service on Windows). Please make that maximum<br>
> value configurable or make it fail a bit more gracefully (first wait 2<br>
> seconds, then 4, then 8 or whatever you do to increase the wait time)<br>
> instead of going directly to the max. value.<br>
<br>
</div>You can change the maximum time with the MaxTimeout configuration variable.<br>
Also, tinc 1.1 doesn't rely on signals anymore, you will be able to tell tinc<br>
to immediately try reconnecting using the tincctl program.<br>
<div class="im"><br>
> I tried to set up a<br>
> backup program to run after boot - but then the tinc interface doesn't<br>
> come up for 15 minutes after booting, which screws the whole process<br>
> and confuses the hell out of that poor program too... ;-)<br>
<br>
</div>For now just add something like "MaxTimeout = 30" to tinc.conf :)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Met vriendelijke groet / with kind regards,<br>
     Guus Sliepen <<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>><br>
</div></div><br>_______________________________________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br>
<br></blockquote></div><br>