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 <[email protected]> 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 <[email protected]> > > _______________________________________________ > tinc mailing list > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
