mdlayher / consrv Goto Github PK

In my setup, for whichever reason, the USB-to-serial adapter occasionally drops off the USB bus and comes back as ttyUSB1 instead of ttyUSB0:

[776891.671139] cp210x ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[776891.680238] cp210x ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[776891.764819] usb 1-1-port3: disabled by hub (EMI?), re-enabling...
[776891.772885] usb 1-1.3: USB disconnect, device number 6
[776891.779671] cp210x ttyUSB1: failed set request 0x12 status: -19
[776891.786843] cp210x ttyUSB1: failed set request 0x0 status: -19
[776891.794229] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
[776891.802492] cp210x 1-1.3:1.0: device disconnected
[776892.031977] usb 1-1.3: new full-speed USB device number 7 using dwc2
[776892.143732] cp210x 1-1.3:1.0: cp210x converter detected
[776892.151568] usb 1-1.3: cp210x converter now attached to ttyUSB0

I don’t know yet if this correlates to any specific trigger (perhaps rebooting my router?), but it happens frequently enough to be noticeable.

This behavior can be reproduced by physically un-plugging the USB-to-serial adapter and plugging it back in.

On the Go side, the symptom is that Read() returns an io.EOF error.

Currently, consrv connections just hang indefinitely until you send a byte, which triggers a write to the ttyUSB0 device, which triggers a write /dev/ttyUSB1: input/output error that then closes the SSH session.

There are a number of things subtly wrong that result in the silent swallowing of the error. I can send a PR that addresses enough of them to make the SSH session close immediately when un-plugging the adapter.

What’s still left to be done is closing the mux device and underlying serial port, and then re-opening it on the next connection.

I've seen lots of questions about what exactly this does, so I should explain it better.

Hi @stapelberg / @mdlayher

Let me start with this, "This project solves a real problem" of making serial connection accessible over SSH.
I can see a lot of use cases where this project could bring a lot of value for ex :

1. Getting console access of network switches/firewalls for remote (over the internet) management (and trust me there are millions of such devices on the ground)
2. Getting console access of servers (over the internet) think about edge computing where we do not have a datacenter, just have one machine lying in the toll plaza etc. Management of those devices over the internet could be a boon.
3. And don't forget IoT devices etc

I am very much interested to contribute to this project (i have just started to learn go) but i can at least contribute in testing this end-to-end , writing documentation/blogs/videos (if that is considered as contribution 👯 )

Before i can do the above, i need to setup a homelab and try out consrv , based on my experience i will test this and document my journey in blogs/readme/examples etc.

Is there a slack/irc/discord group where you guys hangout, i would like to join that and be a part of this journey.

Hey 👋

I started using consrv recently (blog post coming soonish) :)

I not only use serial console for interactive on-demand access, but also for continuous, always-on logging.

Because I started suspending my PC to RAM over night, I have gaps in my serial console logs.

I was wondering what you think about making consrv store serial logs (either in RAM, and/or on disk) while the client is disconnected? Once the client reconnects, consrv would stream what the client missed.

Thanks