search

dani007200964 / Shellminator

Shellminator is a shimple shell interface for embedded devices
https://www.shellminator.org/
MIT License
84 stars 7 forks source link

How tro use Shellminator with Telnet Client #5

Closed 0xAF closed 2 years ago

0xAF commented 2 years ago

Thank you for your great work on Shellminator.

I can see in the code, that there is a way to use the shell with WiFiClient. Please provide some example how to use it with telnet client and what library is appropriate for this job (i.e. ESPTelnet).

Thanks you!

dani007200964 commented 2 years ago

Hello!

The library is compatible with the builtin WiFiClient objects. However, I do not had time to create a separate example for that ( yet ). But there is a video tutorial with an example code:

In this video I demonstrate how to use this library from the ground up. If you need only the WiFiClient section, it starts about 42:01.

In the future weeks, if I have some free time, I will create an example to show just the WiFiClient usage. I will try to create an example with the ESPTelnet library if it's needed.

0xAF commented 2 years ago

Thank you very much for the information.

  1. The video is quite enough to get me started, thanks.
  2. The link to the example is invalid, perhaps the repository is private?
  3. I've tried to get WiFiClient object from ESPTelnet, but as it seems it's private for the class, so I did not managed to make it work. That's why I've decided to ask you.

Thanks for the information and your great work on the project.

dani007200964 commented 2 years ago

Sorry, the example was private, I changed it to public! Please check it. In the next weeks, I will try to implement a simpler way in Shellminator itself to handle WiFi client.

dani007200964 commented 2 years ago

Hi @0xAF !

I have created a prototype in the dev branch:

Please if you have some free time test the code in the dev branch. Itt looks good to me, and much simpler, than the solution in the tutorial video.

If you find any problems, please let me know!

0xAF commented 2 years ago

Hi Daniel, Big thanks for your efforts and the good work. However, there are some issues. I'm using linux and the standard linux telnet and netcat clients.

Here are the issues and some screen casts, so you can see for yourself.

With standard telnet client: screen cast

  1. There is flickering, I would guess it's because of RedrawLine(). (not a big deal, but still annoying)
  2. The first command is accepted and executed correctly, but any other command is not read.

With netcat (nc) client: screen cast

  1. The first command is read, but enter key does not execute the command, hence the buffer is filling with the next commands. (the buffer is cut at some length, hence in the screen cast you cannot see the filling of the buffer, sorry for that) (note: there is no flickering with the netcat client. I would guess the nc is not sending char by char to server, but the whole string in one packet.)

EDIT: I've tested putty for linux and it works as expected in putty. I guess there is some issue in the "enter key" handling, because if the characters it produces. I've debugged a bit with the telnet client and it sends "0x0D" (\r) for enter key. So I guess the reading of the next lines is dependent on the "\n" somehow? But don't bet on my words, better test for yourself.

dani007200964 commented 2 years ago

Hi Stanislav,

First off, Cool logo, I like it! :)

  1. I have done some investigation into the problems. The NetCat version does not seem to be useable. As I understand it has only local line editing, this is why it's looking wierd. Shellminator has to process the text, instead of the terminal client. The other problem with NetCat is, the line ending is only \n. Every other terminal client that I have used, creates a line ending starting with \r. I think I will leave NetCat compatibility for the future, because there are at least two working solutions.
  2. Command execution problem: I don't know why, but some terminal clients( like screen and nc ) ends the line sometimes with \0. I have never seen this with PuTTY or Minicom, so I have not handled this case. If \0 character gets into the buffer, it terminates the string in it. This is why only the first command worked. It has been fixed.
  3. Linux usage: I have tested the functionalities with a Raspberry Pi, and it seems to work fine with PuTTY and screen as well. If you want to use some GUI, PuTTY can be a good choice. However If you want to connect from the Linux terminal, I recommend screen. It is a very usefull command and works with TCP and serial port as well. To use it: screen //telnet IP PORT, for example screen //telnet 192.168.100.1 23.

https://user-images.githubusercontent.com/26076131/189827068-dd65c631-0d9a-4ac5-aa96-f81d868e561f.mp4

https://user-images.githubusercontent.com/26076131/189827338-1ed60f28-352b-4d59-a254-0d72f9e682ac.mp4

  1. Flickering problem:. If you just type in the command it won't be a problem. But if you edit the line, it will be there. I didn't know how to implement it without line redrawing, and in my tests it was usable. Not pretty, but not unusable.

EDIT: I'm working on another solution right now, which uses the xTerm.js API to host a webpage with a terminal. It's at a very early stage, but if it works, it can be more platform independent, and it only requires a modern browser. I hope I can finish it in this month, I could use it in my next project.

0xAF commented 2 years ago

Hi Daniel, Thanks for the quick response.

First off, Cool logo, I like it! :)

https://textfancy.com/text-art/

  1. I have done some investigation into the problems. The NetCat version does not seem to be useable. As I understand it has only local line editing, this is why it's looking wierd. Shellminator has to process the text, instead of the terminal client. The other problem with NetCat is, the line ending is only \n. Every other terminal client that I have used, creates a line ending starting with \r. I think I will leave NetCat compatibility for the future, because there are at least two working solutions.

Yeah, you are correct for the netcat client and it's absolutely reasonable to leave it behind for now (or forever).

  1. Command execution problem: I don't know why, but some terminal clients( like screen and nc ) ends the line sometimes with \0. I have never seen this with PuTTY or Minicom, so I have not handled this case. If \0 character gets into the buffer, it terminates the string in it. This is why only the first command worked. It has been fixed.

Ohh, I never imagined that some client could send \0 in the end, but I guess this is because they interpret the lines by themselves and send the buffer to the server on \n. As you explained above.

  1. Linux usage: I have tested the functionalities with a Raspberry Pi, and it seems to work fine with PuTTY and screen as well. If you want to use some GUI, PuTTY can be a good choice. However If you want to connect from the Linux terminal, I recommend screen. It is a very usefull command and works with TCP and serial port as well. To use it: screen //telnet IP PORT, for example screen //telnet 192.168.100.1 23.

For me, the most popular and used client in Linux is the pure old telnet client. So, I would say the telnet client is the top priority.

  1. Flickering problem:. If you just type in the command it won't be a problem. But if you edit the line, it will be there. I didn't know how to implement it without line redrawing, and in my tests it was usable. Not pretty, but not unusable.

I agree, it is usable at the moment, the flickering is just annoying, but not a problem for the usability.

EDIT: I'm working on another solution right now, which uses the xTerm.js API to host a webpage with a terminal. It's at a very early stage, but if it works, it can be more platform independent, and it only requires a modern browser. I hope I can finish it in this month, I could use it in my next project.

I've saw your commits, and I agree this would be a more viable solution for most people. But, as I said above, to me the telnet is top priority, because most linux users with experience would prefer that.

Please excuse me, for not testing more deeply myself. I just did not had the time last night. I will try to do more deep testing and eventually fixing if I find more problems in the next days.

Thanks again, I will try the latest version this night and will report back to you with information and some PR if there is a need for that.

0xAF commented 2 years ago

The flickering problem could be easily solved I guess. I just had a look at the code of redrawLine(), more precisely here You're sending ANSI CSI \e[2K and then returning the cursor to position 0 with \r. \e[2K will erase the whole line, and later you will populate the line with the banner again, hence the flickering.

What I suggest is to change the logic as follows:

  1. return to position 0 with \r
  2. print the banner (which will print over the old/existing banner on the line)
  3. send ANSI CSI \e[0K, which will erase from the cursor to the end of the line.

I think this will solve the flickering problem.

I will try tonight and send you a PR if this fixes the issue.

dani007200964 commented 2 years ago

For me, the most popular and used client in Linux is the pure old telnet client. So, I would say the telnet client is the top priority.

I agree, it should be fixed first. I tested telnet with the '\0' fix. It seems to work fine with every command, not just the first. After I get home I will try to investigate the flickering thing. I don't know why, but the good old telnet is much slower then PuTTY of Screen. Maybe the age :)

https://user-images.githubusercontent.com/26076131/189939378-f1bff6b3-40c9-4526-a9a9-d5fd36fd0cc3.mp4

  1. return to position 0 with \r
  2. print the banner (which will print over the old/existing banner on the line)
  3. send ANSI CSI \e[0K, which will erase from the cursor to the end of the line.

Sounds a better solution than mine. I think the second step can be accelerated a bit more with the [ESC [ pn C](http://www.braun-home.net/michael/info/misc/VT100_commands.htm) command. It only requires to save the banner length, but it is easy. In this case the banner reprinting stuff can be skipped.

0xAF commented 2 years ago

Hi Daniel.

I believe this issue can be closed now, since you've provided a way to connect with telnet client and fixed the issues. I've made a PR with other fixes and some additions. Please consider this issue as fixed. I'm not gonna close it, just in case you have something in mind.