tmate: timeout session openning and close it properly

[germanferrero]

Right know our uhttpd endpoint for openning a tmate session will create a new session and wait for the tmate-ready signal. If the router has no connectivity with the tmate server uhttpd will kill the script, but the session will remain created.

Example using ubus directly.

root@LiMe-abcd00:/# ubus call tmate open_session
Command failed: Request timed out
root@LiMe-abcd00:/# ubus call tmate get_session
{
	"status": "ok",
	"session": {
		"rw_ssh": "",
		"ro_ssh": "",
		"clients": ""
	}
}

The desired behavior is that open_session set up a timeout on tmate's command wait tmate-ready and close the session if the timeout is reached. For that we could use busybox's timeout command here: https://github.com/libremesh/lime-packages/blob/36c6030f50a31965c0f5179ecb004413b26e83c3/packages/ubus-tmate/files/usr/lib/lua/tmate.lua#L44

busybox's timeout needs to be included in the compilation adding 6kb (AFAIU) to the compiled image using: CONFIG_BUSYBOX_CONFIG_TIMEOUT=y

Another option is to send a close_session request from the client who request open_session before, but it is no robust.

Is something we want to address?

[spiccinini]

I would say that the API of session creation should create the session "in the background" (returnin the ubus answer right away). What do you think?

[nicopace]

Maybe we need to change the semantics, instead of open_session, it could be a request_session ... the success of that request would be for the request to be received, but the session doesn't necessarily be created... you would need to ask if it was created or not.

[germanferrero]

Yes, that semantic will work too. We can address this as an enhancement later on since https://github.com/libremesh/lime-app/pull/296 already fixes this from the LimeApp perspective.

[ilario]

Any update on this? Is still an issue?