5

I have a second monitor that I'd like to use for a text-based debugging log and/or console. I don't want to have it as part of my GUI / "desktop" / main system.

I have this display connected to an old linux box that doesn't have much processing power. When it boots up it sits ready at the login: prompt.

It is connected to the LAN so I can SSH to it. I know I can write to the screen by running something like ssh root@ancient echo test \> /dev/tty0

I enjoy using named pipes for debugging, basically creating one named pipe with mkfifo and then using tail -f on it while writing data to it from other commands / scripts / etc.

Based on this explanation of what I'm attempting to do, what is a "good" / "right" way to do what I'm trying to do ("dump data" to a named pipe over the network so that the output would appear on this terminal's screen? )

I know I've got access to ssh, tail, netcat (nc), and redirection via things like /dev/tty0 - but I can't quite figure out how to put it all together eloquently. I did see this: Can I pipe/redirect a console application through netcat so it can be used remotely?

It seems hackish to use something like ssh root@ancient echo test \> /dev/tty0 and create a new connection for every log item that gets sent.

A bonus would be if the data was not sent over the network as plain-text, but I suppose that criterion is not mandatory if it makes things very slow or creates too much overhead or complication.

Also, would there be any advantage in using a serial connection between the two machines instead?

I have done this in the past but it seemed to me that even at the maximum baud rate of 115,200 that when a few hundred lines of code were sent it seemed 'laggy' compared to sending the data over the network. I know 115k is old "modem technology" so I just wanted to know if this slower-than-expected experience for this type of direct ( albeit serial) connection is normal.

2
  • 1
    Is there a reason that tail -f fifo | ssh root@ancient cat \> /dev/tty0 doesn't work for you? I'm inferring that it doesn't but I'm not sure why. Aug 20, 2014 at 3:56
  • @MichaelHomer - thanks, that seems to work well
    – cwd
    Aug 21, 2014 at 17:33

3 Answers 3

3

netcat springs to mind; it may be the more sensible choice (given the no-overhead, no compression approach to network communications) on your low-spec receiving machine.

A nice usage example can be found here:
https://stackoverflow.com/questions/4113986/example-of-using-named-pipes-in-linux-bash

1
  • That might be the solution. Let me do some testing and I will be back to select this as the solution if I have some luck. Thank you
    – cwd
    Aug 20, 2014 at 19:47
2

You can use tail -f the way you're accustomed to, and pipe that across an ssh connection to the other machine:

tail -f fifo | ssh root@ancient cat \> /dev/tty0

You run cat > /dev/tty0 on the other side, which will echo its input back out onto the terminal. ssh will pass the output from tail into the standard input of cat across the network. All the data is fully encrypted in transit

A serial connection would work, but unless one of the machines is very weak the overhead of ssh and network traffic will be negligible.

0

it should be enough using

cat > /dev/udp/ancient/12345

on one machine and

nc -lu 12345

on the other. If you want to use TCP for reliability just remove the -u option from nc and replace /udp/ with /tcp on the redirection

2
  • Well, there is no /dev/dcp or /dev/udp folder in the file system. At least not on Arch linux.
    – Arne
    Mar 3, 2018 at 17:54
  • 1
    @Arne they are special pseudo-devices on linux (see tldp.org/LDP/abs/html/devref1.html)
    – jdowner
    Sep 25, 2020 at 13:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .