ANSI Escape sequence unexpected output

ANSI Escape sequence unexpected output

[David Wang (王振宇)]

Hi all,
    when I use the host console via uart to log in to os, sometimes some unexpected output is print to stdout, such as:

login: root
Password:
Last Login:  Thu   Jan   7  06:52:18  UTC  2021  on ttyS0
root@intel-corei7-64:~#  ;153R     <-------  This is the unexpected output

It also happen when using obmc-console-client or ipmitool sol activate.
It looks like an ANSI Escape sequence
"EscLine;ColumnR	Response: cursor is at v,h	CPR"
ref: http://ascii-table.com/ansi-escape-sequences-vt-100.php
ref: https://stackoverflow.com/questions/16026858/reading-the-device-status-report-ansi-escape-sequence-reply

My question is,
how to prevent this escape sequence from printing to the stdout?
Which package in openbmc is doing this?
Has anyone had a similar problem?
Please leave any comments.
Thanks

David

Re: ANSI Escape sequence unexpected output

[Jeremy Kerr]

Hi David,

>     when I use the host console via uart to log in to os, sometimes
> some unexpected output is print to stdout, such as:
> 
> login: root
> Password:
> Last Login:  Thu   Jan   7  06:52:18  UTC  2021  on ttyS0
> root@intel-corei7-64:~#  ;153R     <-------  This is the unexpected
> output

It looks like you're only receiving part of the full ANSI escape
sequence there (I assume this escape sequence is coming from host
during the initial shell setup). This may happen if the serial
connection to the host is dropping characters.

Do you also see characters dropped if you output a large amount of data
from the host? Perhaps try a `ls -l /usr/bin` and see if the output
formatting looks OK.

What is the hardware serial connection between the host and the BMC
here? Does it provide hardware flow control?

Regards,


Jeremy

Re: ANSI Escape sequence unexpected output

[Johnathan Mantey]

[-- Attachment #1.1: Type: text/plain, Size: 2282 bytes --]

David,
I see a garbage sequence like this all the time.

I run an Expect script that controls my terminal emulator (kermit), and 
I see a sequence like this:
[[39;88R
I have tried multiple times to have Expect eat or delete this output 
before handing control to my terminal emulator.
Once Expect hands control I see:
;88R

I have also tried modifying settings in my terminal emulator to see if 
the ANSI sequence would be eaten by the terminal emulator. This has also 
been ineffective.

So once my Expect script has handed control to me, I have to manually 
press CR to clear the excess bytes.
This gives me an error message from Bash:
-sh: syntax error near unexpected token `;'

So I know the characters are in the Bash input stream.
Like you, I have no idea where they are coming from, and all my 
mitigation attempts have failed.

None of my compatriots have the issue, so far as I know. When I brought 
this to the attention of some of my team members, none claimed to have 
the same issue. As my toolset is the outlier in the group, I just 
resigned myself to suffering with the issue.

On 2/17/21 11:11 PM, David Wang (王振宇) wrote:
> Hi all,
>      when I use the host console via uart to log in to os, sometimes some unexpected output is print to stdout, such as:
>
> login: root
> Password:
> Last Login:  Thu   Jan   7  06:52:18  UTC  2021  on ttyS0
> root@intel-corei7-64:~#  ;153R     <-------  This is the unexpected output
>
> It also happen when using obmc-console-client or ipmitool sol activate.
> It looks like an ANSI Escape sequence
> "EscLine;ColumnR	Response: cursor is at v,h	CPR"
> ref: http://ascii-table.com/ansi-escape-sequences-vt-100.php
> ref: https://stackoverflow.com/questions/16026858/reading-the-device-status-report-ansi-escape-sequence-reply
>
> My question is,
> how to prevent this escape sequence from printing to the stdout?
> Which package in openbmc is doing this?
> Has anyone had a similar problem?
> Please leave any comments.
> Thanks
>
> David
>

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: ANSI Escape sequence unexpected output

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]


Johnathan Mantey <johnathanx.mantey@intel.com> wrote:
    > David, I see a garbage sequence like this all the time.

    > I run an Expect script that controls my terminal emulator (kermit), and
    > I see a sequence like this: [[39;88R I have tried multiple times to

That's the result of a Device-Status Report.
https://en.wikipedia.org/wiki/ANSI_escape_code#CSIsection, see "DSR" or "CSI 6n"
39 88 is the size of your terminal, or the one that Kermit is emulating for you.
(I seem to recall think that kermit has a full-screen mode. So many different
versions of it over the decades)
You may be able to turn kermit responding off, or change it's terminal type
to dumb.

The shell is emitting ESC [ 6n to set the stty size of the terminal.
"resize" does this, but I think gnureadline does too.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: ANSI Escape sequence unexpected output

[Johnathan Mantey]

[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]

On 2/18/21 9:37 AM, Michael Richardson wrote:
> Johnathan Mantey <johnathanx.mantey@intel.com> wrote:
>      > David, I see a garbage sequence like this all the time.
>
>      > I run an Expect script that controls my terminal emulator (kermit), and
>      > I see a sequence like this: [[39;88R I have tried multiple times to
>
> That's the result of a Device-Status Report.
> https://en.wikipedia.org/wiki/ANSI_escape_code#CSIsection, see "DSR" or "CSI 6n"
> 39 88 is the size of your terminal, or the one that Kermit is emulating for you.
> (I seem to recall think that kermit has a full-screen mode. So many different
> versions of it over the decades)
> You may be able to turn kermit responding off, or change it's terminal type
> to dumb.
>
> The shell is emitting ESC [ 6n to set the stty size of the terminal.
> "resize" does this, but I think gnureadline does too.
Thanks for the information.

This motivated me to mess with this again.
FWIW, The DSR command is present when I run Kermit from within a TMux frame.
This code, [[40;162R, is present when I run without TMux, and just use 
Konsole.
Both sequences are emitted AFTER the password has been input, and accepted.

Password:
Last login: Thu Feb 18 19:45:28 UTC 2021 on ttyS4
^[[39;81Rroot@intel-obmc

Using "set terminal type dumb" did not impact the emission of the ESC 
sequence.
I haven't found the "turn responding off" control yet.

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

RE: ANSI Escape sequence unexpected output

[David Wang (王振宇)]

I don't think this is a problem of dropping charecters.
The error seems to occur only at the first time after boot.

> This motivated me to mess with this again.
> FWIW, The DSR command is present when I run Kermit from within a TMux frame.
> This code, [[40;162R, is present when I run without TMux, and just use 
> Konsole.
> Both sequences are emitted AFTER the password has been input, and accepted.

> Password:
> Last login: Thu Feb 18 19:45:28 UTC 2021 on ttyS4
> ^[[39;81Rroot at intel-obmc

> Using "set terminal type dumb" did not impact the emission of the ESC 
> sequence.
> I haven't found the "turn responding off" control yet.

I think this is not like a terminal problem, but the escape charecter is not read correctly and the remaining string is output to stdout. Please correct me if there is an error.
I have found similar codes under linux:
https://github.com/openbmc/linux/blob/599d7f997930829f13e05d332e3e7fccd89d340d/drivers/tty/vt/vt.c#L1829
But I tried to insert the debug code to verify but found that they don’t seem to be the culprit.

Re: ANSI Escape sequence unexpected output

[Johnathan Mantey]

[-- Attachment #1.1: Type: text/plain, Size: 2505 bytes --]



On 2/23/21 12:12 AM, David Wang (王振宇) wrote:
> I don't think this is a problem of dropping charecters.
> The error seems to occur only at the first time after boot.

The issue only happens for me the first time the BMC boots.
If I logout, and log back in, the ESC sequence does not happen.

>
>> This motivated me to mess with this again.
>> FWIW, The DSR command is present when I run Kermit from within a TMux frame.
>> This code, [[40;162R, is present when I run without TMux, and just use
>> Konsole.
>> Both sequences are emitted AFTER the password has been input, and accepted.
>> Password:
>> Last login: Thu Feb 18 19:45:28 UTC 2021 on ttyS4
>> ^[[39;81Rroot at intel-obmc
>> Using "set terminal type dumb" did not impact the emission of the ESC
>> sequence.
>> I haven't found the "turn responding off" control yet.
> I think this is not like a terminal problem, but the escape charecter is not read correctly and the remaining string is output to stdout. Please correct me if there is an error.
> I have found similar codes under linux:
> https://github.com/openbmc/linux/blob/599d7f997930829f13e05d332e3e7fccd89d340d/drivers/tty/vt/vt.c#L1829
> But I tried to insert the debug code to verify but found that they don’t seem to be the culprit.

I don't believe my issue is dropped characters either. Some program 
during the boot sequence is sending the ESC sequence (It is printed in 
full in the capture above), and there isn't a consumer of the value, so 
it eventually lands in the BASH command line buffer.
I find it interesting that I can have Expect run any number of commands 
to the terminal until I tell Expect to hand control to me via the 
"interact" command. Once Expect has given me control of the IO stream, 
the trailing edge of the ESC sequence (i.e. the portion from the ";" and 
after) is pending input to the BASH interpreter. Something in the whole 
process ate the "ESC [39" portion of the sequence, and left the ";\d+R" 
portion alone. This email trail encouraged me to investigate a bit more. 
I have "solved" this issue for myself by having the "interact" command 
clear any sequence that has the ";\d+R" signature. This is not ideal. At 
the same time it solves an outstanding irritation.

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey@intel.com <mailto:johnathanx.mantey@intel.com>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]