Escape characters printed as literals, and issues with line vs character mode in TCP/telnet #105
Comments
|
Hi @qupada, first off sorry the the delayed reaction. This is a rather complex writeup, so I had to read it multiple times and experiment on my machine. Character mode works perfectly though, control characters get transmitted in binary and work as expected. Even including arrow keys to go through shell history and logout with ^D. Example login attempt: Compared to your log (ble lines filtered out to make it easier to read) Here telnet sends the same messages, doesn't get a null terminator back, but suddenly at the end as literal... Overall I think the culprit is the interaction between WSL getty and telnet. I noticed it sends telnet commands With the mix of Linux and Windows it's likely something related to line endings, before auth there is only CR on Windows: https://support.microsoft.com/de-de/topic/telnet-client-does-not-send-crlf-when-expected-e6b9008b-e27e-7a7b-b669-ff0ead89943e After auth it's different depending on config: btw: you could also use TCP in Putty, described in the readme: https://github.com/Jakeler/ble-serial?tab=readme-ov-file#windows |
Describe the bug
Using 2.8.0 installed from PIP on Windows 11, with Python 3.12 from the Windows Store. Also used com0com version 2.x (set up using
install portname=com10 portname=com11from CLI installer), as 3.0 had the all too familiar signing issues.While trying to find a way to operate the serial console entirely inside a WSL2 environment (pass-through of straight COM ports apparently is no longer operational, only works in WSL1), I decided to try the socket option, presuming any standard telnet client would be sufficient.
I created a serial cross-over adapter with two RJ45 punch-down jacks (connecting pins 4+5 straight through, swapping pins 3/6), plugged a USB serial adapter into the PC, attached that to WSL with
usbipd.exeand spawned a login prompt on it withsudo agetty -L ttyUSB0 9600 vt102Connection to the Bluetooth adapter was lanched with:
ble-serial.exe -d "48:87:2D:9C:01:51" --expose-tcp-host 172.25.128.1 --expose-tcp-port 5000 -vOnce port 5000 was listening, connecting a telnet client (tested both
telnetandinetutils-telnet, orscreen //telnetin WSL, and PuTTY on the Windows host) produced the Linux login prompt, but most input was repeated (as if both local and remote echo was happening). Entering the username printed it a second time, and send a 2nd \n which submitted the password prompt too.Attempting to change local echo, line endings, etc in Telnet made no appreciable difference to the outcome, neither did most of the options to
agetty(I didn't try other getty implementations however).Using COM port mode with
ble-serial.exe -d "48:87:2D:9C:01:51" -p COM10does not exhibit this behaviour, only TCP.
Log messages
Exact series of operations, swinging for minimum number of lines of console output:
usbipd.exe attach -b 2-2 --wsl.usb-serial.exe.telnet 172.25.128.1 5000.sudo agetty -L ttyUSB0 9600 vt102(should immediately produce Linux login prompt in telnet)And the output received in the telnet window (repeated newlines are visible):
Switching from line to character mode in telnet with
^] mode characteralmost fixes the issue, but some escape characters appear to be misinterpreted:Specifically, if switching to COM port mode, I do not see these lines when pressing enter on the password prompt:
but instead this (ignoring the "no job control" message, this is at least a successful login):
Amongst other things I've tried, trying to force character mode from either
.telnetrcdoes not appear to be functional as it appears to refuse to apply these options unless port 23 is in use, nor by sending telnet control characters from the host (ie per https://stackoverflow.com/questions/273261/force-telnet-client-into-character-mode) directly viaecho $'\377\375\042\377\373\001' | sudo tee /dev/ttyUSB0or similar. The^]method to inputmode characterseems most reliable, but is irritatingly non-automatable.At this point I'm not sure whether it's a matter of one too many translations between layers of this unholy pancake stack, or now it's something that I personally am doing wrong.
I should also note my attempt to use TCP here is in large part in aid of not having to consider terminal baud rate at any part of the process. The Bluetooth adapter I purchased features hardware switching between 2400/4800/9600/19200/38400/57600/115200 rates, and I presume what arrives over the air has shed any notion of that serial port speed, indeed I can connect the virtual com port at 115200 while the terminal connected from the PC to the bluetooth adapter is at 9600.
Setup:
Additional Context
While using a USB serial adapter in this way is my contrived but easily-reproduced (as both ends of the connection can exist and be controlled on the same PC) example, I tested this with the real hardware console port on an switch made by Arista Networks and it exhibits the same behaviour. Again, direct COM port mode in PuTTY works perfectly.
After successful login, am still seing random
^@appear, and some newlines being printed as a literal^Min the console instead of a newline:Line mode (duplicated text, duplicate newlines, password not hidden):
Character mode (escape characters printed literally):
Note I've attempted to obfuscate hostnames, usernames and passwords, so please excuse if I've cut out a line anywhere I shouldn't. I've run a serial line from my switch at home to my office now, so I can plug into it without getting up from my desk, if there's anything needing to be clarified or further tested.
The text was updated successfully, but these errors were encountered: