-
Well, I have witnessed this a couple of times over the last two weeks, once vtun took 5 hours before closing a dead connection. I suspect the OpenWrt side, but I am at a loss...
Please let me know if there are any more or other tests I can run to diagnose this problem further...
2009-10-07 20:53:01 UTC by jserfontein
-
And it happened again, but luckily I saw it happening and did got some more info :
The client's ADSL connection dropped at 00:57:34 and reconnected at 00:58:06, but the tunnel's session only closed at 01:14:37 with an "Invalid argument (22)" message. The tunnel reconnected at 01:14:42.
The server closed the tunnel session at 01:14:09 with a "No route to host (113)"...
2009-09-24 23:37:06 UTC by jserfontein
-
I'm glad that your tunnels have hit a stable state. I'm not so optimistic as to believe that they're fixed, yet, but after a month or two I may grudgingly agree that they're reliable enough to be used. ;-)
I haven't set up Quagga yet, but it's on the Radar. That, and DHCP over /30 ethertap links.
I can't recommend ZLib over LZO or the reverse; while LZO is newer, I don't expect it'll...
2009-09-22 02:50:47 UTC by mtbishop
-
Sorry for only getting back to you now, but I think my issue might be resolved. All the connections have been running smoothly for about 4 days now, ever since I removed the "device" settings, and changed "persist keep" to "persist yes".
Btw, it would seem that "persist keep" with "multi killold" causes some errors... as should probably be...
2009-09-21 20:43:24 UTC by jserfontein
-
I got the configs. Thanks. I like what you're doing for the clients in up/down.
I notice the clients aren't doing keepalive; I think the clients are the most important peer to run keepalives with, since while the server can kill the stale tunnel, the client has to notice the tunnel's stale and then reconnect. I'm wondering if - if you're PPPoE vs Vanilla DSL like here - the outer PPP...
2009-09-16 01:13:09 UTC by mtbishop
-
Yes, 5 idle tunnels with keepalive, and only the 1 tunnel (Vtun 2.6) sending echo requests. Btw, there is actually a 6th tunnel (server mode), also idle, and also no echo requests.
From a logical point of view, a parent process definately makes sense, although I have no idea about the practical implications in this case. As for reporting overhead, if it is well designed and thought out, the...
2009-09-15 14:09:27 UTC by jserfontein
-
5 Tunnels idle, all with keepalive on, and only one of them is sending pings? And it's also the only 2.6 client?
After some more consideration, I'm not sure a management interface would work as we want it to. VTun processes are separate and don't fork from a central one like apache processes, for instance, so they don't have a trivial method of reporting status to the parent, which we could...
2009-09-15 00:18:17 UTC by mtbishop
-
Well, I actually thought it might only send pings when the link is idle, so I removed all routes to the remote networks, and kept an eye on the iptables' counters, which stayed at 0, so all the links were definately idle.
If by "maybe we'd be better served by an interface", you mean some
form of management and reporting interface, I couldn't agree more,
and while my programming...
2009-09-14 21:17:23 UTC by jserfontein
-
That's okay if the other ones are quiet in terms of ping -- it's only sent when the link itself is idle otherwise.
Hmm. The ping really is a smoke test to see if the link really is idle. maybe we'd be better served by an interface (like ndc for named) to show us whether the link is idle/pinged/not in terms of traffic. The ping only tell us who'd be terminated if 4 pings were to go unheard.
2009-09-14 20:35:24 UTC by mtbishop
-
Ok, new Vtun compiled and running with "ping patch", and oddly enough, only one of the 5 clients are "sending ping" ( in 30 second intervals ), and that client, is the only one running Vtun 2.6-7... otherwise identical setup.
2009-09-14 19:51:41 UTC by jserfontein
