Junk in RX callback after client disconnects

[cocus]

Hello; I've tried the provided example with an Ethernet PHY (rather than wifi). Everything works, but there's a problem when the telnet client disconnects, which causes the RX callback to read gibberish. This is the output of said issue:

I (88404) main.c: task_led_toggle: cnt: 176
I (88904) main.c: task_led_toggle: cnt: 177
I (89404) main.c: task_led_toggle: cnt: 178
I (89904) main.c: task_led_toggle: cnt: 179
I (90404) main.c: task_led_toggle: cnt: 180
I (90604) main.c: Received 3 bytes from telnet: ~
I (90614) main.c: Received 1691 bytes from telnet: 
I (90614) main.c: Received 1 bytes from telnet: �
I (90614) main.c: Received 445 bytes from telnet: ?�
I (90614) main.c: Received 47 bytes from telnet: ~� [�?�y@?�[�?����������������@
I (90634) main.c: Received 1 bytes from telnet: �
I (90634) main.c: Received 1 bytes from telnet: �
I (90634) main.c: Received 140 bytes from telnet: ��������������������������������������������������������������������������������������������#
I (90654) main.c: Received 1 bytes from telnet: �
I (90654) main.c: Received 1 bytes from telnet: �
I (90654) main.c: Received 92 bytes from telnet: ������������   
I (90674) main.c: Received 1 bytes from telnet: �
I (90674) main.c: Received 1 bytes from telnet: �
I (90674) main.c: Received 20 bytes from telnet: 
I (90694) main.c: Received 1 bytes from telnet: �
I (90694) main.c: Received 1 bytes from telnet: �
I (90694) main.c: Received 460 bytes from telnet: #
I (90694) main.c: Received 1 bytes from telnet: �
I (90714) main.c: Received 1 bytes from telnet: �
I (90714) main.c: Received 68 bytes from telnet: 
I (90714) main.c: Received 1 bytes from telnet: �
I (90734) main.c: Received 58 bytes from telnet: ?�
I (90734) main.c: Received 1 bytes from telnet: �

Note that the last "valid" char was ~ (I was trying the escape sequence of ssh, not the one for telnet, which is ^]). I'm running telnet on WSL, the build itself on windows.

The spam continues forever.

[h2zero]

Hello, thank you for the report. I have tried to reproduce this but I have not been able to. Is there anything in your code that may cause this?

[cocus]

I'm using your example code, but using an ethernet adapter rather than WiFi. I also start the telnet server when the ethernet gets connected (blocking with the GroupBits rtos api). Then I connect through my PC, which it works and prints the buffer. However, after disconnecting, it starts to freak out in the console. My guess is that the socket didn't close? I'm not sure, I'll add more debug to figure it out. I didn't try to phyisically disconnect the cable, but I'll see if the task ends at that case.

Just in case, this is the info about my env and chip:

IDF Version:5.3.1
Chip info:
        model:ESP32
        cores:2
        feature:/802.11bgn/BLE/BT/External-Flash:8 MB
        revision number:301

As a side note, do you know how to redirect the input from the telnet session to the stdin? I've seen some comments on this thread but I don't know if that would be compatible with your code. I assume I only need to change the stdin on the _GLOBAL_REENT, but it doesn't make much sense to me if other tasks are already waiting on the file descriptor of stdin (like with select() or read with blocking mode).

I just want to replicate the linenoise console on telnet, since the console component of idf is quite useful.

[h2zero]

Sounds good, let me know what you find with your debugging as the issue is hard to repro.

Redirecting stdin in your code will not conflict with this library, probably a good addition as an option though.

[cocus]

Wasn't able to reproduce it lately.. So I think it's okay to close. However, I'm a little bit puzzled as to how to redirect the stdin to the connected client. Have you ever tried this before? If so, do you mind sharing it? Because this seems to be a little bit of a black magic hack in the esp-idf.

[h2zero]

I have not tried to redirect stdin, it should work the same as it does for stdout though.

I found this: https://esp32.com/viewtopic.php?t=6711

[cocus]

Right, that's the one I've linked before, and I think it might work but it sounds very destructive. Whoever is waiting for input on the stdin (with 'select' or similar) they'll get a nasty error when I close the stdin. The problem would be that the example seems to create a new vfs device but it sets a callback for rx, not tx (i. e. if you press a key). In the end, my goal is to have the repl console working on telnet, but I tried redirecting the stdin by changing the global stdin to the socket fd, but didn't work. I will have a look at trying to create a new repl console haandler for telnet (instead of serial), and see if that works. it's interesting that no one had this idea/issue before!

El mié, 13 de nov de 2024, 19:46, h2zero @.***> escribió:

I have not tried to redirect stdin, it should work the same as it does for stdout though.

I found this: https://esp32.com/viewtopic.php?t=6711

— Reply to this email directly, view it on GitHub https://github.com/h2zero/esp-libtelnet/issues/1#issuecomment-2474977652, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD73TV6VUINKJSWELMQITL2APJD3AVCNFSM6AAAAABQNK5UO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHE3TONRVGI . You are receiving this because you authored the thread.Message ID: @.***>