Issue with connection about eternalterminal

[MisterTea]

can you try running et with bash -x and see what et is doing differently than you? Also can you share what you did manually to get it to work?
Example:

bash -x et myhost:myport

[Pyrepenol]

Got it. Looks like Fish shell on my server might be the culprit. I'll try it now with Bash instead.

Authenticated to *** ([***]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
Expected a string, but instead found a redirection
fish: debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
done <<< "$ET_SERVER_COMMANDS"
^
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 3488, received 5476 bytes, in 0.1 seconds
Bytes per second: sent 30536.2, received 47940.4
debug1: Exit status 127

[Pyrepenol]

Just tried it with /bin/bash and /bin/sh and they both gave the same output, besides the fish:debug1 line.

The way I got it to work previously was by manually starting etserver and etclient. I didn't have to do anything but provide the connection details and the encryption key from a previous connection attempt.

I forgot to mention that the client is on WSL, I'm not sure if that's relevant.

edit: Looking at the log files, it seems they only are storing one line at a time for whatever reason. Strange.

et_err contains "ERROR: unknown command line flag 'alsologtostderr'"

etserver.INFO ends with "I0322 12:04:02.005519 1118 TerminalServer.cpp:219] Creating server"

sshd -d on the server ends the connection with:

Starting session: shell for *** from *** port 55437 id 0
Received disconnect from *** port 55437:11: disconnected by user
Disconnected from *** port 55437

Which is strange because I'm not using port 55437? I'm rather stumped to be honest.

[MisterTea]

It looks like you built your own binary and are using a version of glog that doesn't depend on gflags.
What's WSL?

[Pyrepenol]

Windows subsystem for Linux. Lets me run bash directly on windows 10. I'm also using it with Arch on both the client and server, so I had to manually install all the dependencies. I just spent an hour or so trying to make sure they were installed correctly and I believe they are.

[MisterTea]

Ok got it: So when you build glog, you can choose to link in gflags and enable flags for logging. "alsologtostderr" is one of these flags that you only get if you build glog with gflags support. I guess when you built glog you didn't depend on gflags and this is why you don't have the alsologtostderr flag.

Please build glog with gflags support and try again.

[MisterTea]

Actually when you said "install all the dependencies" did you mean build from source, or use arch's install? If Arch's version of glog doesn't have flag support, that's a bigger problem.

[MisterTea]

In the meantime a workaround is to remove the --alsologtostderr flag from the launcher: https://github.com/MisterTea/EternalTCP/blob/master/launcher/et#L109

[MisterTea]

Ah yeah, ArchLinux's glog doesn't depend on gflags. Here's a workaround: https://bbs.archlinux.org/viewtopic.php?id=212838

[MisterTea]

@Pyrepenol Let me know if any of those solutions worked for you, thanks!