Mosh: Can't use mosh on Termux

[Vivraan]

mosh complains that the locale on Termux (en_US.UTF-8) only provides with US-ASCII, and Termux doesn't support locale-gen - how does it work?

[keithw]

I think you need to take this up with Termux, sorry. You can include us on the question/bug report and we can try to chime in if they can't figure it out. Good luck!

[Vivraan]

So mosh doesn't work with US-ASCII?
I've had this trouble on a regular Linux machine and it was trivially solved by using locale-gen. This is not possible in Termux, as I've already mentioned.

[Vivraan]

Plus, https://github.com/termux/termux-packages/issues/5743 indicates that it usually works in Termux, but I just can't figure out why it's not working in my case alone.

[keithw]

These seem like good questions for Termux... If you want us to try to help,
please paste the full error message you are getting (the whole thing).
Right now I don't know if the error message is coming from mosh-client or
mosh-server.

On Sun, Aug 30, 2020, 2:40 AM Shivam Mukherjee [e-mail]
wrote:

Plus, termux/termux-packages#5743
https://github.com/termux/termux-packages/issues/5743 indicates that it
usually works in Termux, but I just can't figure out why it's not working
in my case alone.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mobile-shell/mosh/issues/1112#issuecomment-683398908,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABTAO5PLKQGTD3CR3KUU2DSDIM7DANCNFSM4QO5UBMA
.

[Vivraan]

Indeed. Here's what I get:

$ mosh [email protected]
The authenticity of host '192.168.1.49 (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:{KEY-OMITTED}.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.49' (ECDSA) to the list of known hosts.
Enter passphrase for key '/data/data/com.termux/files/home/.ssh/id_rsa':
The locale requested by LANG=en_US.UTF-8 isn't available here.
Running `locale-gen en_US.UTF-8' may be necessary.

mosh-server needs a UTF-8 native locale to run.

Unfortunately, the local environment ([no charset variables]) specifies
the character set "US-ASCII",

The client-supplied environment (LANG=en_US.UTF-8) specifies
the character set "US-ASCII".

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Connection to 192.168.1.49 closed.
mosh: Did not find mosh server startup message.
$

Note that LC_ALL has no value since I erroneously changed it once as part of a suggested fix.

[keithw]

Ok, the error is coming from the server and suggests that the server does not have a working en_US.UTF-8 locale, independent of Mosh. What is the platform/architecture/OS running on the server? (Termux on a smartphone?)

[Vivraan]

It probably isn't an issue with the server - the server (Manjaro KDE) itself uses en_IN.UTF-8 and works perfectly with other systems (Manjaro KDE, Windows 10/Ubuntu 20.04 via WSL 2) using the same locale.

The difference is that these systems support locale-gen, whereas Termux explicitly uses a modified glibc and hence doesn't provide any locale configuration tooling. Its default is set to en_US.UTF-8, but as you can see, it's not registering as UTF compliant.

This same issue occurred on the Manjaro client earlier, and I trivially solved it by running locale-gen.

If you're hinting that it's a server problem, then clearly this is an issue worth considering because I've demonstrated that this is actually a problem on the client device.

[Vivraan]

This occurs only when I try to connect to a mosh server using a mosh client on Termux, running on Realme UI v1.0/Android 10.

Please refer to the issue I've made on the Termux repo: https://github.com/termux/termux-packages/issues/5753.

[keithw]

Is it possible that the server has a en_IS.UTF-8 locale but doesn't have en_US.UTF-8? You may need to generate a U.S. locale (en_US.UTF-8) on the server, or change the LANG environment variable on the client to ask the server for an Indian locale (en_IN.UTF-8). You could also attempt to start the server with an Indian locale (use LANG=en_IN.UTF-8 mosh-server as the client's server command line) so the server doesn't have to depend on the client's choice of locale.

I don't quite understand why you are talking about termux not supporting locale-gen -- it's the server that needs to generate the locale, not the client. That's why I was confused by your message (which seemed to suggest the server was Termux).

[Vivraan]

I see. Let me get back to you on this.

[keithw]

The issue here (and this is unfortunately not specific to Mosh) is that the client and server need to speak the same language for you to get proper locale handling. You'll have the same problem with SSH and locale-aware programs when connecting between these two machines -- it's just that Mosh is much stricter and won't let you start the session at all with a broken setup, whereas SSH doesn't care and lets the individual programs complain or be flaky later if they feel inclined. (Perl is one program that will happily complain.)

So either the server needs to know how to speak U.S. English (as requested by the client) or the client needs to start asking for Indian English (as supported by the server). Unfortunately there is no supported/deployed convention for a "just give me UTF-8 gosh darn it!" locale in POSIX without agreeing on a common language. :-/ We have seen this in the issues with people connecting from Canada to the U.K., Australia to the U.S., etc. :-(

[Vivraan]

Welp, the explicit LANG setting to the Indian locale worked. This was not clear to me through the docs - is it available anywhere, or can this be added somewhere?

Seems like this sort of thing should be automatic if both client and server support UTF-8 compliant locales - the server obviously doesn't have the US locale enabled since I assumed that having anything with UTF-8 in it would work.

[keithw]

Sure, please feel free to edit our Wiki to make this clearer (and you can probably find other people with similar issues in the past to link to if you want). This is really just a question of education about how the C/POSIX locale mechanism works and is not specific to Mosh, but of course because we're strict about this we end up being the first time people become aware of the incompatibility. We've tried to make the error messages very specific and precise about what's going on, but of course we could probably do more handholding in the error message too.

[Vivraan]

I'd be happy to contribute to the wiki, but IMO this just feels like a slap to the face when the image Mosh provides (at least to me) is one of "Set this up and you're absolutely good to go, say goodbye to all compliance troubles."

I'm also not well versed with all of the nitty-gritty details pertaining to this, but I could spare time to update the wiki out of my schedule.

[keithw]

It "should" be automatic, but I guess the way we would have to do that would be to have mosh-server have a fallback mode where it does a brute-force search through a hardcoded list of possible LC_CTYPE variables to see if any of them happen to be available on the server. (Like, we'd put a list of the world's languages into the source code and have it try them all to see if the server supports any of them.) This is sort of counter to the philosophy of Mosh, which is more like, "We'll help you get your stuff configured properly and then it will work dependably in the face of network problems, or at least will tell you upfront when it loses connectivity," not, "We will silently choose a language for you that you didn't ask for and mask the incompatibility that you had between client and server until one day it stops working because the server admin deleted the Azerbaijani locale that mosh-server was secretly depending on."

[Vivraan]

That is a much clearer message than what I found on the docs page, so if you would let me quote you on that, I'd be happy to add that! 😁

[keithw]

Quote whatever you want. Let's hope nobody from Azerbaijan gets offended.

[Vivraan]

However does this mean that some UTF-8 locales from the same language may use characters not present in other locales?

It feels like a situation where this could be supplied as an option (say -automagically-choose-best-locale), and which could be disabled by default. Otherwise, you'd have to know which locales your server has set up before making connections. Would there be a situation where that isn't the case? An example would be a remote server which has a specific locale set up.

The error message merely hinted that I was using the wrong locale, not that the server actually used something different (and indeed from the same language), or that the server was using the Indian locale when I was supplying it the US one, which it didn't recognise.

Mosh assumes its users to be lettered in locale specifics, which while trivially changeable causes hiccups where conventional software, even while doing it badly, configures out of the box. Had I not known this, I would have removed mosh and continued with plain old SSH.

[Vivraan]

It "should" be automatic, but I guess the way we would have to do that would be to have mosh-server have a fallback mode where it does a brute-force search through a hardcoded list of possible LC_CTYPE variables to see if any of them happen to be available on the server. (Like, we'd put a list of the world's languages into the source code and have it try them all to see if the server supports any of them.)

iinw one could simply do something akin to what ssh-copy-id does and either add the necessary locale and call locale-gen on it or read the remote server's set LC_ALL variable instead of iterating through its locale gen conf file.

[keithw]

It's not quite that "the server was using the Indian locale" -- the processes on the server have no idea what locales/languages are available without brute-force trying a bunch. This is just the way that C and POSIX work. You know as a human that the server has en_IN.UTF-8 available (and maybe you have a shell rc file or PAM config file that sets this environment variable when you log in with an interactive session) but there's no way for a process to know that without brute-force searching through all the world's languages. The server might have Indian English, Canadian English, French French, and Austrian German all available; there's no specified way for a user-space process to know which one the user is willing to accept when its actual selection (U.S. English) is unavailable.

In this case, the client is requesting en_US.UTF-8 and the server process tries that and gets a failure; that's sort of the end of the line without a lot of "automagic" (like reading /etc/locale.gen) that we generally avoid. We're kind of big on being explicit/predictable, maybe at the expense of "it just works...... for now."

[Vivraan]

Well you should capture by now that it wasn't predictable at all. If it
were explicit it should've been documented.

Can the environment variables not be queried? If they can, could a simple setup
step like finding the current server locale through the LC_* variables be used
instead of a more costly check on the locale gen conf? This could be an
optional arg, as I've suggested.

ssh-copy-id essentially copies the public fingerprint of a given client to
the server by temporarily opening a connection to it, writing to its sshd
conf and then exiting. This could as well be used in mosh, optionally, at
O(1) cost if the variables to be queried are known.

Or, at the very least, the server should echo back what locale it uses through the environment variables. This obviously must change the semantics of mosh-server.

On Tue, 1 Sep 2020, 4:13 am Keith Winstein, [e-mail]
wrote:

It's not quite that "the server was using the Indian locale" -- the
processes on the server have no idea what locales/languages are available
without brute-force trying a bunch. This is just the way that C and POSIX
work. You know as a human that the server has en_IN.UTF-8 available
(and maybe you have a shell rc file or PAM config file that sets this
environment variable when you log in with an interactive session) but
there's no way for a process to know that without brute-force searching
through all the world's languages.

In this case, the client is requesting en_US.UTF-8 and the server process
tries that and gets a failure; that's sort of the end of the line without a
lot of "automagic" (like reading /etc/locale.gen) that we generally avoid.
We're kind of big on being explicit/predictable, maybe at the expense of
"it just works...... for now."

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mobile-shell/mosh/issues/1112#issuecomment-684080843,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADBPQXD6NFR6OZJ3M6XBX3TSDQRP5ANCNFSM4QO5UBMA
.

[Vivraan]

I haven't exactly skimmed through the rest of the issues but wouldn't you agree that enforcing a vision through a tool is the fastest way to alienate potential blocks of users with little prior understanding of how the application works? If it "just works" it shouldn't be published, because it "must work with least surprises" to be a useful UX, but this is strongly my own opinion.

[Vivraan]

Consider again, a situation where a client must open connections to multiple servers on several processes to perform some kind of activity. The utility of mosh is that the connections are guaranteed to be much better than ye standarde SSH, but there is no guarantee that the server's locale would be known beforehand.

If their locales can be queried optionally, it saves significant effort in managing these sessions, and if this is not desirable then the standard setup can be used which saves computations and bandwidth if the servers' locale are known beforehand.

[Vivraan]

Anyways none of this off-topic stuff is productive discussion if it is not taken note of. I'll open a PR/suggest edits to the wiki soon.

[keithw]

The server's environment variables are already printed out in the error message you saw ("[no charset variables]"). Your sshd is starting mosh-server without any locale-related environment variables. So the only environment it can even try is the one it's getting from the client (LANG=en_US.UTF-8) and that one isn't available on that server either. The server admin could have configured sshd to start processes with a LANG environment variable (corresponding to some locale that exists on the server), but this particular computer just wasn't configured that way.

Unfortunately there is no such thing in C/POSIX/Unix as "the server's locale." The server may have any of a number of locales built and available. The question is whether the software is able to name any of them! And I understand your frustration (it's not like you're the first person to run into this -- Mosh has been around for almost nine years at this point and has been this pedantic since the beginning), but this is really not a Mosh issue. It is related to the way locale is designed on C/POSIX/Unix in general. You will have the same problem if you use SSH to connect from this client to this server, except instead of a fatal error and pedantic technical diagnostic message at startup, instead you'll just get generic flakiness and occasional warning messages.

Some people like things to "sort of work," even if they are partly broken, and are willing to tolerate flakiness or errors on the screen down the road. Mosh, I'm afraid, wants to yell at you to fix your broken setup before it's willing to start working for you. (And if we're doing volunteer tech support, we would rather help somebody understand a clear error message than try to diagnose random flakiness that they blame us for.) I realize this is a design approach you disagree with.

[Vivraan]

As I said, an optional switch should be in place so that people like me who haven't done their homework do not run into these problems.

Otherwise, it is commendable that mosh does identify that the server doesn't have a compatible locale, I completely missed that. Yet it would be useful if this could be moved from locale level to charset level. Maybe if my server doesn't have a proper UTF-8 locale set up properly, it would warn me back suggesting that a (set of) given UTF-8 locale(s) should be tried, with a copy of the command

LANG=locale.CHARSET mosh host@address

when it finds the error, instead of only hinting that locale-gen may need to be run, since it is misleading on average and causes people like me to begin harebrained disputes at worst.

[Vivraan]

In summary, the docs need updating, and I will definitely be doing that when possible, or if someone beats me to it - expressive docs and error logs are a source of joy for all.

[keithw]

https://www.jwz.org/gruntle/autobogotification.html