ASTERISK-21854: Long Asterisk-version strings display improperly in the 'Connected to ...' line upon remote console connection

[Home]

Summary: ASTERISK-21854: Long Asterisk-version strings display improperly in the 'Connected to ...' line upon remote console connection

Reporter: klaus3000 (klaus3000) Labels:

Date Opened: 2013-06-03 06:16:13 Date Closed: 2015-04-01 15:40:15

Priority: Minor Regression?

Status: Closed/Complete Components: General

Versions: 11.4.0 Frequency of
Occurrence Constant

Related
Issues:

Environment: Attachments:

Description: When using a long version string in file ".version", the presented string when connecting to the Asterisk CLI looks corrupted. See following example: the string printed directly is correct, the "Connected to" string (which shows the version received via the socket from the server) is broken:

{noformat}
# rasterisk
Asterisk 11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890, Copyright (C) 1999 - 2012 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 11.4.0 89012345678901234567890123456789012345678901234567890123456789▒▒ ▒ currently running on hvst (pid = 28190)
0123456789012345678901234567890
hvst*CLI>
{noformat}

The bug exists since version 1.4.

Comments: By: Matt Jordan (mjordan) 2013-06-03 12:01:05.364-0500

Hey Klaus!

What string did you use in .version?
By: klaus3000 (klaus3000) 2013-06-03 12:06:53.219-0500

Hi Matt! Sorry for not mentioning that. The string in .version is (in total 100 characters):

11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
By: Matt Jordan (mjordan) 2013-06-03 12:45:24.952-0500

Just for curiosity's sake, why the long version string?
By: klaus3000 (klaus3000) 2013-06-03 13:24:42.752-0500

Above is of course just for testing. But in real live I use version strings which indicate the patches I added to the plain Asterisk, e.g:

1.4.17 with-CLEARMODE-with-T38-fix-with-config-option-XYZ-with-foobar-with-security-AST-2013-.....

So, my version strings are sometimes really long :-)
By: Rusty Newton (rnewton) 2013-06-03 16:59:51.257-0500

Using the same string: "11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"

I consistently get the following output on a -r connection to asterisk:
{noformat}
Connected to Asterisk 11.4.0 890123456789012345678901234567890123456789012345678901234567 currently running on ubuntu (pid = 13048)
890123456789012345678901234567890
{noformat}

Looks like an issue occurring only where the version string is displayed when connecting with a remote console.

Some of the other places you can see the version string:

{noformat}
asterisk -V
Asterisk 11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
{noformat}

{noformat}
root@ubuntu:/usr/src/asterisk-11.4.0# asterisk -c
Asterisk 11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890, Copyright (C) 1999 - 2012 Digium, Inc. and others.
{noformat}

{noformat}
*CLI> core show settings

PBX Core settings
-----------------
Version: 11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
{noformat}

{noformat}
*CLI> core show version
Asterisk 11.4.0 890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 built by root @ ubuntu on a x86_64 running Linux on 2013-05-22 20:02:45 UTC
{noformat}
By: klaus3000 (klaus3000) 2013-06-03 17:51:15.004-0500

That's also my conclusion. The version string gets corrupted when displayed from the rasterisk "client" side.

the strange thing is also, that the string gets truncated, but the missing characters are displayed after the log message:

{{Connected to Asterisk 11.4.0 89012345678901234567890123456789012345678901234567890123456789▒▒ ▒ currently running on hvst (pid = 28190)}}
{{*0123456789012345678901234567890*}}

By: Di-Shi Sun (homesick) 2013-06-05 08:50:15.856-0500

The issue is main/asterisk.c/ast_remotecontrol defines buf variable with fixed size 80. It cannot store a long "<hostname>/<cpid>/<version>\n" string. It may use a larger buffer or allocate enough memory for it.
By: klaus3000 (klaus3000) 2013-06-06 06:30:16.514-0500

Indeed. A Quick fix is:
{noformat}
char buf[80] = {0};
...
if (read(ast_consock, buf, sizeof(buf)-1) < 0) {
{noformat}
By: Di-Shi Sun (homesick) 2013-06-06 08:09:24

Hi Klaus3000,

Your quick fix does not work. I have tried it.

A simple fix is to use buf[256] or buf[512].
By: klaus3000 (klaus3000) 2013-06-06 10:42:23.495-0500

I do not understand why this fix does not work for you.

Further, just increasing the buffer size is not a fix. The problem is, that read() starts after sizeof(buf) characters. If the string is longer than buf, then the terminating \0 is missing. Thus, my fix should be better:

1. char buf[80] = {0};

This initializes the whole array to \0 characters

2. if (read(ast_consock, buf, sizeof(buf)-1) < 0) {

This reads only 79 characters, thus keeps the last character as \0 (as long nobody else uses buf before the read command. So the string will be truncated, but is always \0 terminated.

This works fine for me with 11.4.0. Maybe you are using another version which uses "buf" after initialization, but before the read command.

By: Di-Shi Sun (homesick) 2013-06-06 21:03:30.052-0500

I tested it on trunk r390664. It did not work.

I think buf must store all "<hostname>/<cpid>/<version>\n". Otherwise, some info will be missed. In fact, hostname part itself may be longer than 80 too.

By: klaus3000 (klaus3000) 2013-06-07 08:17:09.987-0500

My "quick fix" should prevent reading data from behind buf[79]. Actually you are correct - a proper fix should be able to handle arbitrary lengths, e.g. reading first line from server until \n and dynamically adjust alocate memory to fit the whole string.
By: Di-Shi Sun (homesick) 2013-06-07 09:55:26.706-0500

In fact, the thing mostly confusing me is why your fix does not work as expect on trunk r390664. I expect a truncated version sting and clear after pid info in the log. But it still has tail after pid info.
By: klaus3000 (klaus3000) 2013-06-10 07:07:04.191-0500

The problem is, that the read() only read the first 80 chars of the version string. Thus, my fix only makes this read() more secure, but does not read until \n.

Thus, I suspect that the "normal CLI operation" which just read() text from the server reads the rest of the version string and displays it - just like any other text sent to the CLI.
By: Di-Shi Sun (homesick) 2013-06-10 19:15:46.043-0500

I believe you are right. It looks like the only way to fix it is to adjust buffer size dynamically.
By: Mark Michelson (mmichelson) 2015-04-01 15:40:15.189-0500

I'm closing this issue as the fix made on December 9, 2013 in the Asterisk 13 branch should be sufficient to fix this problem. I am backporting the change to the 11 branch

That patch expands the buffer to 256 characters and ensures that the input that is read is NULL-terminated. While this won't cover infinitely-long version numbers, this should be sufficient to cover any sane versioning scheme that people use. If someone does end up using a >255 character version for their Asterisk installation, then feel free to open a new issue that uses an expandable buffer instead of a fixed buffer.