CLI gibberish -- prompt and input appear to be some sort of unicode characters


#1

When I start CLI, the prompt will appear normal but soon turns into some sort of unicode looking character stream. Inputs are also displayed as unicode and do not execute. Only Ctrl-c seems to work, and only on one of two computers. Here is an example:

Asterisk 13.9.1, Copyright © 1999 - 2014, Digium, Inc. and others.
Created by Mark Spencer markster@digium.com
Asterisk comes with ABSOLUTELY NO WARRANTY; type ‘core show warranty’ for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type ‘core show license’ for details.

Connected to Asterisk 13.9.1 currently running on ZSPD (pid = 307)
== TLS/SSL ECDH initialized (automatic), faster PFS ciphers enabled
== TLS/SSL certificate ok
\U+75704

Add a return and the display is:

\U+75704\U+7570A

I’ve looked and looked and come up empty handed.

Oh, CLI worked perfectly for months and then, one day, while running, went into this mode.

Stephen


#2

Try setting nocolor = yes in your asterisk.conf in the [options] setting and see if that helps.


#3

Tried. No change.

Thank you for the suggestion, though!

I’ve searched a lot on this and I really am amazed that’s I’ve found absolutely nothing. Apparently, I’m the only person who has experienced this.

Stephen


#4

Just because I forgot to mention it, Did you restart asterisk with a ‘core restart’ after changing asterisk.conf?

what’s the hostname of your machine, could it have special characters in it?

Does the asterisk console work correctly locally on the physical machine?


#5

In fact, I combined it with a kernel update and rebooted the entire machine.

Initially after I start CLI the display and prompt will be:

Only once there is some input or output will the prompt change. A lower case “c” gave me this:

A little later, once I have some output, it looks like this:

I have been accessing the machine using SSH. I would need to hook a monitor up to it to do as you suggest. I have been considering doing so. I have logged in with SSH from two different machines but both have been running Arch Linux (as is ZSPD).

Stephen


#6

That is super strange.

I’ve never seen anything like this.


#7

You would think that someone else would have had this problem but no matter how much I search, I come up with nothing.

I upgraded to 13.10.0 last night. No change.

Anyway, thank you for your help!

Stephen


#8

I have the same problem, i’m running asterisk 13 LTS on arch.
Tried connecting directly on the linux console (keyboard+monitor instead of ssh) but I get the same result. As FixedWing reports, i can’t find much info around on that issue, tried nocolor but it doens’t help.

Just as a sidenote, i can enter 1 command on the asterisk cli if I connect to it directly without using the bash prompt with:

ssh myasteriskserver asterisk -rvvv

Then I can enter a single command and it will be executed. All subsequent commands will fail because a garbage character seems to be inserted at some point.


#9

I am sorry that you are having this issue but also pleased to hear that I am not alone.

So, the common denominator appears to be Arch Linux. But I searched their forum earlier and didn’t see anything.

FYI, I am currently using linux-grsec 4.6.4.201607242014-1 on i686 architecture. I’ve updated the kernel a few times since this has happened. I’ve also updated Asterisk once.

It does make sense that it must be some program in the Arch install collection as it literally happened while the program was running. Before that, no problem whatsoever.

Stephen


#10

I’m using Linux alarm 3.14.65-16-ARCH on arm. i’m kinda glad to know it isn’t due to the arm environment… :wink:
You say it happened after a kernel update? Did you have to rebuild asterisk or just did it happen just after rebooting?
I tried to play with the locale/language/input environment parameters but same results…
I’m pretty sure i had it working correctly last month, I’ll try to find an old image.

Vincent


#11

Probably not a kernel update, that’s something that is different between the two of us, but probably the update of some other component. It literally happened one day when CLI had been running for a while. I went to bed and it was fine. I woke up in the morning and it was not fine. Unfortunately, by the time I’d thought about it enough to conclude that it was some component that had been upgraded, it was too late for me to figure out which component (assuming I’m even right, which I could easily not be).

Stephen


#12

Well i got an old image (± 1 month old), rebuild asterisk 13 lts, and the cli is just fine. I’ll try to make small updates and see which one breaks it…


#13

Well if the bug comes from a single package, it’s one of these… I ran an update on a batch, didn’t really expect any of them to be the culprit (except systemd maybe…) But after i ran the update, without even rebooting or restarting asterisk, the bug appears…

Packages (17) libarchive-3.2.1-2 libassuan-2.4.3-1 libedit-20160618_3.1-1 libffi-3.2.1-2 libgcrypt-1.7.2-1 libgpg-error-1.24-1
libmnl-1.0.4-1 libsasl-2.1.26-8 libsystemd-230-7 nano-2.6.1-1 netctl-1.12-2 pam-1.3.0-1 procps-ng-3.3.12-1
s-nail-14.8.9-1 systemd-230-7 systemd-sysvcompat-230-7 tzdata-2016f-1


#14

I would hazard a guess that it’s libedit.

In the CHANGES file for Asterisk:

  • Asterisk can now use a system-provided NetBSD editline library (libedit) if it is available.

#15

Nice work!

My bet is libedit:

http://thrysoee.dk/editline/

Stephen


#16

Right on target :slight_smile:
I reverted back to an old image and updated everything but libedit, and the cli is fine.
Just for the sake of completeness:
Works: libedit 20150325_3.1-2
Glitches: libedit-20160618_3.1-1

Not sure if the bug is in asterisk or libedit, but libedit might stay out of date for a little while on my servers :wink:
Thanks both for your help

Vincent


#17

Nice work!

I’m thinking that the only reason that this is just affecting us, is that Arch is probably one of the few installs that is using libedit.

Stephen


#18

Hi guys,

I’m having the same issue with alarm. Is there an easy way to fix this problem? Which version of Asterisk does the problem first appear in? Or is the problem just with libedit? Is there a way i can rollback libedit on alarm?

Thanks,
Luke


#19

Hi Luke,

there are two ways to fix the problem:

  • downgrade libedit to the version described in Vincent’s post of July 27th: get the tar.xz from somewhere (maybe your package cache?: /var/cache/pacman/pkg/), invoke pacman -U on the package file, that should downgrade it. CLI should be working again after restarting asterisk. You yet have to be careful that on any system update you do from then on (pacman -Syu) to add --ignore libedit otherwise pacman will update your libedit back to the latest version!
  • my solution was yet different as I did not want to downgrade the system libedit (is used by other packages too and I am not sure about security fixes): as I build asterisk myself anyway, I added --without-libedit to its configure -line. This will force asterisk to build & use its own internal version of libedit, and not the one found in the system. That way, asterisk is independent of any updates to the Arch version of the lib.

Hope it helps,
H.


#20

I love this solution! I will do this the next time I build Asterisk. Thank you.

But meanwhile, there must be something about the configuration of libedit within Arch which is causing these problems. That would be the final solution. Anyone have any idea what it might be?

Stephen