2009-09-15 00:18:17 UTC
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 ideally query. But this would be interesting:
[root@binky ~]# vtun-status
3441 - tun0 - up (22d29h31m14s) - seattle2bothell - UDP - idle - ping1 - lzo:5 - zlib9
23656 - tun1 - down (00d01h13m42s) - bothell2vancouver - re-establishing
5927 - tun2 - up (14d22h59m51s) - WestDevTrunk - TCP - active - 100k/s - lzo:1 - zlib:9
Yes, that would be a nice snapshot.
There has been some thought - especially if we get connectionless protocols like a pipsec-ish setup - that we'd need to look into a central parent process and maybe children, but the separate process nature of the TCP and callback-UDP connection styles doesn't lend itself well - IMHO - to forking from the parent -- on the client especially, or, with people like me, when vtund is started via inet.
And would the potential performance hit of constantly signaling the parent be an okay cost just to have the snapshot state at-hand?
I just looked at the openVPN docs, and wow has that project become big. But, in comparison,
Keepalive YES
Keepalive 30:4
, here, is like
--ping 30 --ping-exit 120
there, I think. The default (main.c:88) is 30 second on the poll(), and 4 missed polls before the link bails (linkfd.c:267).
The burning question though, is still: when the keepalive-generated traffic over the TCP socket is bounced, why is the socket not killed? It's only DSL clients, right?
