Let SOcket CAT Be Thy Glue over Serial | Hacker News Reader

Let SOcket CAT Be Thy Glue over Serial

bloggerbust.ca

79 pointstodsacerdoti31 comments

Also, try `screen`

  screen /dev/ttyS0 
  screen /dev/ttyUSB0 115200

You can specify baud rate (defaults to 9600), and a number of other parameters. Some of these are nicely documented at https://www.cyberciti.biz/faq/unix-linux-apple-osx-bsd-scree... if you dislike reading the entire man page for screen(1).

There's a very nice write up about the socat command line interface here [1] in case anyone is interested.

[1] https://medium.com/@copyconstruct/socat-29453e9fc8a6

If you want neither Minicom nor Screen, and Socat is a bit too minimal, there is dterm[1]

[1] http://www.knossos.net.nz/resources/free-software/dterm

On the other end of the scale, if minicom doesn't have enough features, there's Kermit. Especially handy if you need to script "expect" style functionality over serial. http://www.kermitproject.org/

I imagine many will go see if tmux does it as well. Tmux appears to not want that feature: https://github.com/tmux/tmux/issues/1862

I agree with the assertion by the tmux maintainers that screen probably shouldn't do it either.

whats the advantage over just using something like cu inside a tmux window?

https://man.openbsd.org/cu.1

One issue with using screen for these purposes is that it will silently drop \xFF bytes. In my case I was trying to pull an image off of an Arduino or RPI connected camera, and my images would arrive like 99% accurate (mostly correct headers etc) but would not open in any image viewing program. Took a long time before I realized that transferring the data via screen was causing the corruption.

That's somewhat curious. Do you know why screen does anything special with 11111111?

The problem with this, and likely why the post was made in the first place, is screen and many other solutions are basically just a terminal emulator on your existing terminal emulator and may cause problems. screen for instance seems to make snippets I use to resize serial terminals nonfunctional, likely because it does not implement things the same as xterm-like terminals.

For a standard serial terminal I also really like the `miniterm.py` script that is included with the PySerial Python package.

    miniterm.py /dev/ttyUSB0 115200

It's just a basic serial terminal but it covers all of my use cases (mostly interfacing with embedded devices).

socat + "everything as a file" lets you network up stuff only designed to be used over a serial link too, which I've found super useful. Wireless calibration of a drone using software that only supports USB serial? Hook it up to a raspberry pi in AP mode, stick some socats with udp on one side and /dev/ttyUSB0 on the other, boom, now you can talk to the flight controller untethered with 10 minutes reading the man page for socat and some trial and error.

I'm using socat to emulate a PTY that I then run a PPP link over. socat gets its byte stream from an RTL-SDR and send out data using a tiny FM transmitter. After setting up these on both computers, I was able to SSH and ping google over FM radio.

Do you have any page describing it?

I'll be uploading a video to my youtube channel in the coming weeks! Part 1 will be describing the link layer. Part 2 will be full duplex communication.

[0]: https://www.youtube.com/channel/UCsRWsHhvzSoMgVfiNhy0NoA

Is it actually a FM transmitter, or is it FSK? Or something like AFSK?

Right, it is AFSK. The FM transmitter is something off the shelf, for car radios and such, meaning it has a low pass filter installed, along with spitting out a 19khz stereo carrier.

Thats pretty cool, I'll have to check out your video when you put it up. I'm under the impression that at least in the US, the legal limits mean this really wouldn't be useful past 100 feet or so, line of sight. That's assuming little to no co-channel interference and not using impractically large directional antennas on the receive side. Of course if you were able to frequency shift the transmitter up into the 2m band and had an amateur license, you could trivially go miles (and slightly less trivially 10s of miles).

Socat is also useful to hide services that otherwise force themselves on a network interface.

My torrent daemon has no business permanently exposing the Web controls on any network interface - not even localhost, because localhost is potentially accessible by untrusted stuff running in the browser.

I solve this by placing it inside a dedicated, firewalled container, and using socat to forward from a local socket (browser can't access) to the network one. When I need to connect to it via the browser, I do the opposite forwarding (SSH can also forward to local sockets).

Slightly off topic, but socat and lzop are my favorite utilities for shuttling data around a local network at high speed.

Backing up a disk:

    alice$ pv /dev/sda | lzop | socat - tcp:bob:1234
    bob$ socat tcp-listen:1234 - > alice.sda.lzo

Copying a bunch of files:

    alice$ tar c dir | lzop | socat - tcp:bob:1234
    bob$ socat tcp-listen:1234 - | lzop -d | pv | tar x

Do you consider you're on a secure network?

Wouldn't netcat be easier?

Some versions of netcat have no way of closing the connection when the file is finished transferring. You just have to wait long enough and then hit control+c.

In case anybody is interesting, over the last month I used socat as a simple way to transfer serial over IP. Here you can see the "sending" part https://novamostra.com/2020/05/15/rasperry-pi-as-a-usb-gadge... and here https://novamostra.com/2020/05/15/rasperry-pi-as-a-usb-gadge... you can see how you can redirect input from a remote serial device or the local UART port of a Raspberry PI to the Gadget port using socat.

AGH omg I've needed this. I'm connecting a few Digimesh nodes to Arduinos, Macs, and RPIs. Sometimes I just need to reproduce a problem by sending the raw transmission again a few times. I've used minicom, but it's a "little too much" tool for the job.

On OSX I haven't been able to get screen to work properly, not sure why; I've just used minicom.

//Opinion

The issue with socat (and some other tools) is the esoteric argument syntax. Arguments should always be passed as "-s arg" for short option names, or more preferably "--long-name argument" as long names, and multiple different things should be passed as multiple different arguments instead of some crammed way.

Since you can specify several devices on one command line, that might make the number of options too high.

The "cramming" allows the 2nd, 3rd, etc, argument to contextually tie to the first. Like: "/dev/ttyUSB0,b115200,rawer"

ffmpeg (and some other programs) has a different solution to this: options apply to the succeeding non-option argument: ffmpeg -f wav infile -f mp4 outfile means to convert the wav infile to an mp4 outfile. of course, nobody ever reads the manual, so they use it wrong.

I agree with you, it has some bad parsing bugs if you actually want characters like commas and colons as arguments.

What's the difference between netcat and socat?

I thought this was about the old google ctf challenge...

Reply on news.ycombinator.com