Telnet access for Tasmota

[dx136]

I was playing around with serial/UART access and this method of Telnet access kinda popped out of that.
The documentation for Tasmota commands starts with "Commands can be issued using MQTT, web requests, webUI console and serial" (https://tasmota.github.io/docs/Commands/). Now we can add Telnet as a 5th method.

I have consistent, reliable access via Telnet, and hopefully captured all the details below. I will mention that there appear to be some quirks and still-mysterious behaviors in getting to the final solution. Or at least the unexpected behaviours were mysterious to me. Sorry for the loooong post, but I didn't want to leave out any essential details. The basic method relies on creating TCP Serial Tx/Rx ports that are directly (cross-)wired to Serial Tx/Rx ports.

I used a ESP32-S3-Zero module that I purchased on AliExpress; it has plenty of accessible GPIO pins and was very inexpensive (~CDN$5). It turns out that an important (necessary?!!) feature is access to the "native" UART0 Tx/Rx GPIOs: the technique was also successful on a WeAct ESP32-DOWD-V3 (UART0 GPIOs accessible), but not on a ESP32-S2-mini (UART0 not accessible). Further below are pics showing the test wiring, and then final wiring.

Implementation steps are:
Step 0 - May or may not be necessary - one of the "mysterious" quirks; see below.
Step 1A - TCP serial connections require custom compilation using #define USE_TCP_BRIDGE
If you want more than the default of 2 simultaneous connection, use: #define TCP_BRIDGE_CONNECTIONS xxx
Step 1B - In order to compile, I used the excellent tool Tasmocompiler https://github.com/benzino77/tasmocompiler
It takes a couple of minutes to set up your account on GitHub/GitPod and everything else "just works"
Step 1C - Tasmocompiler leaves out a number of features; one I wanted was Serial Bridge; not sure if it's necessary or not
for Telnet to work. In any case, I also added: #define USE_SERIAL_BRIDGE
Step 2 - Download, flash the firmware to the board
Step 3 - In the Configuration, Template, define the serial cross-over pins - for the ESP32-S3-Zero:
UART0 Tx = GPIO43; UART0 Rx = GPIO44; TCP Rx = GPIO12; TCP Tx = GPIO13
(Pics show these pins cross-wired)
Step 4 - Start the TCP server on port 23 - automatically, every boot:
Add (e.g. to rule1): ON system#boot DO backlog tcpstart 23 ENDON
Don't forget to enable the rule, e.g. rule1 1
That should be enough to get a Telnet connection (consistently), but keep reading...
Step 5A - Usually from a cold-boot, I did not get a correct connection - either there was no response to typing or
sometimes it responded as a Serial Bridge (?) type of port, with typing in the Telnet window appearing
as SerialReceived(...) messages in the WebUI console. ... Here's Mysterious Quirk No. 1...
Step 5B - Quirk No. 2 (not so mysterious) is that at the default of 115200 baud, longer messages get truncated
(possibly due to timing/buffer overrun). At 57600 baud, things seem to work perfectly all the time.
Step 6 - Quirk No. 3 - Force a warm-reboot and then suddenly, there's a solid, reliable, consistent Telnet connection for
issuing commands, exactly as in the WebUI console. Fix Quirk No. 1-3 by adding (e.g. to rule1):
ON system#init DO backlog status 1 ENDON
ON StatusPRM#RestartReason=Vbat power on reset DO backlog restart 1 ENDON
ON StatusPRM#Baudrate<115200 DO backlog tcpbaudrate %value% ENDON
ON StatusPRM#Baudrate>=115200 DO backlog baudrate 57600; tcpbaudrate 57600 ENDON
ON StatusPRM#RestartReason=Software reset CPU DO backlog serialbuffer 512 ENDON

At this point, everything should be working perfectly as expected. ... Except if it doesn't, which is Mysterious Quirk No 4. One sign is that the Telnet session behaves as a Serial Bridge connection (see Step 5A). I got this problem consistently after having tried using any other GPIOs other than the native UART0 GPIOs for the Serial Tx/Rx. And this condition was "sticky" and couldn't be reversed, even when things had been working initially, tried using a different GPIOs, and then went back to the native UART0 GPIOs. This was true on multiple boards (ESP32-S3-Zero, ESP32-DOWD-V3).

To fix Mysterious Quirk No. 4, do Step 0 - a complete, total reset of the board (WebUI - Configuration, Reset). Reconfigure everything (Wifi, Template, GPIO assignments, rule(s)), being careful NOT to set Serial Tx/Rx to anything other than the native UART0 GPIOs.

None of this has been tested on an ESP8266 (didn't have a board with a sufficient number of GPIO pins), but it should probably work. Finally, even with 4 simultaneous Telnet connections, everything worked perfectly on the ESP32 boards. Good luck and happy Telnetting.

TEMPORARY wiring for testing (Note: cheap USB charge-only cable, with no wires for data connection!)

Final wiring for permanent Telnet access

[dx136]

One more pic of the Template configuration.

[dx136]

P.S. Reading the issue #23156 reminded me of one more caveat: the Telnet does NOT work if using a USB cable with a data connection (either use a simple USB power block, or use a cheap USB charging-only cable that doesn't have wires for the data). @arendst - Your mention of CDC and serial issues in the above forum post makes me think there may be some relation to the Mysterious Quirks in setting up Telnet.
P.P.S Thanks to Theo and all the other fabulous support team and forum members who are so helpful! :-)

[sfromis]

At least on Linux, here's how you can get telnet to work over ser2net via USB CDC, without having done any configuration in Tasmota.

ser2net -C "8082:raw:600:/dev/ttyACM0:115200 NONE 1STOPBIT 8DATABITS -LOCAL"
telnet localhost 8082

This is of course based on the USB CDC connection being recognized as a serial connection. When having USB connection, this is pretty convenient if you have a case where you need to use telnet instead of "just" serial.

This also works to get telnet over USB when it is not CDC, but the specialized ttyUSB drivers.

[arendst]

Thx for the idea.

It got me thinking of adding a Telnet Server not needing the two UART's. See fbb752d just added to dev branch adding 1k3 code to the code size.

It's default disabled but can be added to the code using define USE_TELNET.

It then still is disabled to keep the security guys happy. You'll have to start the server with a command like Telnet 1 or Telnet <any port>. Stop the server with Telnet 0. The default input buffer size is 255 characters but can be changed on the fly with command TelnetBuffer <size>.

To further keep the security guys out only one session is supported.

[dx136]

Awesome! Thanks very much for doing that. :-)
You scored a bulls-eye about the potential security concerns, and your choices make excellent sense. Despite the non-secure nature of Telnet, it's just so ubiquitous and thus so convenient for automated and remote management. Most of my devices are ESP8266 so this is especially convenient. Thanks again.

[sfromis]

These days, I'd no longer call telnet support "ubiquitous", that term instead applies to using SSH. Telnet is increasingly only available as optional packages you can choose to install, if you don't care much about security (unless you count extensions to support TLS).

Of course, SSH is a much more complex protocol, taking a lot of extra coding to implement, and would not really be feasible on ESP8266.