Not responding after being idle for a long time

[1-1-2]

Runing client on my local router. After a long time like one day without any requesting, link lost responding while tinyvpn still running in the background. And still, link is ESTABLISHED the mean time

client side

$netstat -aunlp | grep tiny
udp        0      0 172.*.*.167:38781     4*.*.*.100:12469     ESTABLISHED 5259/tinyvpn

server side

$ ss -aunlp | grep tiny
UNCONN 0      0              0.0.0.0:12469      0.0.0.0:*    users:(("tinyvpn",pid=1149371,fd=7))

Is this cause the server has a timeout to drop stale link?

[wangyu-]

it's not impossible there is a bug in tinyfecvpn,

but most likely it's your ISP dropping the link (precisely, nat mapping).

tinyfecvpn itself doesn't drop stale link. Also it sends a keep alive packet every 3s (see keep_alive_interval) to try to avoid ISP dropping link. But some ISP may still decide to drop link if it's running long enough.

[1-1-2]

Try restarting client solve the problem. No idea what cause this. Maybe, like you said, the ISP drop the long-term connection. Convincing enough for me. May there be a reconnect strategy like 'no response after x mins'? Initiate a new link to walk around this. Scripts will do this but this might be a good feature?

[wangyu-]

thanks for the suggestion. will consider adding it.

[wangyu-]

May there be a reconnect strategy like 'no response after x mins'? Initiate a new link to walk around this. Scripts will do this but this might be a good feature?

I kind of remember why I didn't implement such a feature in tinyfecvpn. this feature is implemented in udp2raw,  with udp2raw+ tinyfecvpn chained together it works similarly as including this in tinyfecvpn itself, although it's not super convenient. udp2raw acutally does more than this:

if you don't need faketcp, you can use the udp mode of udp2raw. udp mode just works like a normal udp tunnel, no iptables is needed.