Issue regarding terminal settings on serial port

[mohitarora24]

Hi there,

We have been using cligen for a while and it seems to work nicely when accessed over SSH. However on a new device and directly connecting via a console/serial port we are seeing a weird issue regarding garbage characters being showing up when pasting multiple lines at once.

Say I copy paste these 5 commands/lines at once:

just a dummy test command 1
just a dummy test command 2
just a dummy test command 3
just a dummy test command 4
just a dummy test command 5

This is how they are received on the CLI launched via Serial port:

test# just a dummy test command 1
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 1"
test# just a dummy test command 2���������5�
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 2"
test# +jR

i.e. the lines after the 1st one are interpreted as garbage characters.

while on a CLI launched via SSH they are parsed fine:

test# just a dummy test command 1
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 1"
test# just a dummy test command 2
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 2"
test# just a dummy test command 3
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 3"
test# just a dummy test command 4
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 4"
test# just a dummy test command 5
CLI syntax error: Unknown keyword: "just" in "just a dummy test command 5"
test#

With some trial & error we found that commenting this line i.e.

    new_termios.c_iflag |= (IGNBRK|IGNPAR);

resolves the issue on the serial port. Setting either IGNBRK or IGNPAR or both of them brings the issue back but if both are left unset this garbage character issue does not happen.

I do not have much idea about terminal settings & termios. Do you know why we need these bits to be set and any repercussions of keeping these bits unset?

Just for reference these are the default terminal settings of serial port i.e. the content of old_termios:

c_iflag		ICRNL|IUTF8|IXOFF|IXON
c_oflag		ONLCR|OPOST
c_cflag		CLOCAL|CREAD|CSIZE|HUPCL|B38400
c_lflag		ECHO|ECHOCTL|ECHOE|ECHOK|ECHOKE|ICANON|ISIG
c_cc		3,28,127,21,4,0,1,0,17,19,26,0,18,15,23,22,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
c_ispeed	38400
c_ospeed	38400

[olofhagsand]

I dont know, looks like some bit error problems.
I have not seen this reported before. What is your platform?
Setting those flags in upstream would need some more investigation since it could break some other settings, I will ask on the clixon matrix channel if this has been seen.

[mohitarora24]

Okay. Well it is a custom yocto based build and also we have a slightly older version of cligen.

On another device CLI has been working fine on serial console port as well as over SSH.

However when we started on this new device - on serial console line we had issue that any characters typed being echoed back as garbage or any response being sent on CLI was shown as garbage. For this we had to pick the fix: 5eec731 i.e. to change TCSANOW to TCSADRAIN when doing tcsetattr()

Now the issue of garbage characters when pasting multiple lines at once still persists.

[dcornejo]

What strikes me is that if you ignore parity errors and break, it works. This seems like a mismatch of the serial ports - parity, 7/8 bit, and stop bits. I have also seen slight mismatch in speeds cause problems (e.g. 9600 on one end, 9500 on the other). I don't have serial ports to work with right now, but if you could try combinations of IGNBRK and IGNPAR and report back here.

On the subject of multi-line pastes: what is your terminal? I have similar problems when copying from a web browser to iTerm on MacOS. I keep thinking I should figure out why...

[mohitarora24]

Yes, I tested with all 4 combinations and these was weird that these bits are not related to each other and any bit set from them causes issues:

• new_termios.c_iflag |= (IGNBRK|IGNPAR); - Issue
• new_termios.c_iflag |= (IGNPAR); - Issue
• new_termios.c_iflag |= (IGNBRK); - Issue
• // new_termios.c_iflag |= (IGNBRK|IGNPAR); - Works fine

Baud rate seems fine as well. As no issues are seen on bash shell on serial console port. Only in cligen based CLI issues are seen. I checked bash source code & the readline library it uses as well and it does not seem to be touching these bits either.
https://github.com/bminor/bash/blob/ec8113b9861375e4e17b3307372569d429dec814/lib/readline/rltty.c#L503

Terminal I've tested with are multiple - iTerm on MacOS, MobaXTerm on Windows, default GNOME terminal in Oracle Linux, etc. Issue is seen in all of them. Commands I've copied from TextMate but I don't see issues in content being copied as same commands when pasted on a different device console port work fine and also over SSH work fine.

I'm confused as well why this is happening. Locally running some regression we have seen no issues in the CLI behavior by keeping these bits off but still not 100% sure as root cause is not known yet.

[RdyCal81]

I put a logic analyzer on the tx/rx and found something interesting. My serial console port is on a Linux unit we are building. We are running the serial port at 115200bps.

When hitting "tab" from the cli the first character appears to have an extra start bit. This is very consistent. The timing looks off also. 19.8us for the first two bits vs. 22.9 for the two farther in the middle of the byte, and it should be ~17.4us.
Always the first byte, the rest look OK, but the damage is done, even though the console should recover, one would think.
Below is the bad byte vs. the good byte. The first one being bad.

Note: This is only on the cli, normal and debug. I don't see it anywhere on the ssh shell. So, could there be a problem with cligen / protobuf?

[kulpatel]

Any further update on this, i m also seeing similar behaviour where i m invoking vtysh internal from my C function with cligen and couldnt achieve multiline copy paste work. To me it looks like async issue as we are invoking vtysh internally so cligen command pormpt is not in sync with copy paste. Anyway we can solve it?

[olofhagsand]

Maybe someone can analyze/experiment with termios settings in https://github.com/clicon/cligen/blob/master/cligen_getline.c for this issue?

[dcornejo]

maybe related: I am using iTerm2 (Mac, obviously) and have noted that when I cut and paste something with multiple lines, the shell (zsh and i think bash) does not see it as a series of commands - it does not act on any of them until I hit return and then it acts on all of them. i have pondered this for a while, but this is a minor annoyance and not the blocker it is in cligen. i haven't researched it too much, but i am thinking maybe that paste is sending newlines (0x0a) and the shell is looking for carriage return (0x0d) to terminate command input while interpreting the newlines as command line separators... anyways, it was just a thought...

[kulpatel]

In my case do invoke vtysh internally as part of the command, and i see two behaviours here.
I dont see this behaviour for the command where vtysh (FRR) is not being invoked.
1> on Mac- iterm2
Below prompt is not in sync with multiline copy paste here

fmcli# config
fmcli(config)# route-map FMCLI_IPV6_NH permit 1
-match next
 set ipv6 next-hop prefer-global
!
route-map RM_SET permit 10
 set src 10.10.10.4
fmcli(config-route-map)# !
fmcli(config)#

Any flag settings we need to do? Any input will be appreciated here

[kulpatel]

my problem is how we can make clipboard and cligen in sync, i.e. for some reason if command execution is delayed? is there any way we can make cligen and clipboard or terminal way of accepting multiline command in sync?

[olofhagsand]

How do I recreate these issues on a regular ubuntu host?