How to Create a Telnet Interface for an Application - linux

I have come across a couple of proprietary applications on Linux platform which are administered via telnet. Remote telnet is not enabled but on the host you do a telnet session. You get an interface where you enter commands to make the application work. I was wondering how a telnet interface is built for any particular application. Not looking for a step-by-step, just a basic/general/big-picture answer of how one can approach building a telnet interface for an application.

telnet is based on the TCP/IP protocol. To "do" telnet from a C program, you'd start messing with sockets, accept()-ing connections and reading and writing to them using fork()-d threads (that's VERY briefly it).
If the app is already there, and already communicates to the console via stdin/stdout, you can rig a telnet interface on to it using (a) some configuration in your Internet daemon, (x)inetd, or by misusing the Swiss Army knife of TCP/IP, netcat.
The docs for both those programs describe how to set things up, vaguely. If you need more help, you know where to ask!

Related

How to connect to an integrated VM without using SSH tunelling

I want to connect to a locked (cannot be modified and I do not have permissions to log into) windows vm which is hosted in a linux machine. Until now these two machines were communicating via port 2277. However for security reasons, the port 2277 is only accessible via localhost (127.0.0.1).
The original proposed solution was to use ssh-tunneling. However since the hosted windows vm will always stay with the linux machine, so I was thinking something simpler.
This Windows virtual machine has ip 192.168.0.1 and the default gateway is 192.168.0.2. The later is the ip address that my linux machine can see.
After searching the internet I tried
socat TCP4:192.168.0.1:2277,reuseaddr,fork TCP4:127.0.0.1:2277
as well as some other random combinations without success.
My understanding is that this failed because for socat to work both sockets must be open.
However the first one is not open by default (checked with ss -ltn) as I need to run the windows service first (which it cannot run as it cannot communicate with iphost:2277)
Any ideas on how to proceed?
Socat provides the retry=N and forever options to handle situations like this. Thus, try something like this:
socat -d -d TCP4:192.168.0.1:2277,reuseaddr,fork,forever TCP4:127.0.0.1:2277
With the interval=<seconds> option you can specify how long Socat waits after each failed attempt.
It turns out that the command that I wanted was the following
socat tcp-listen:2277,bind=192.168.0.1,fork,reuseaddr tcp:127.0.0.1:2277
The retry=N and forever options could be also useful.

How to set up a tcp server on a personal computer

I'm not that experienced with networking - hence why I'm asking this question - so please have patience with my inexperience.
What I want to do is set up a server on my computer that my friend's computer could connect to through the internet and we could play a game (very surprising indeed). A vague idea that I had was I could run a VM to handle it. My questions are:
Is there a way I could establish a connection between our computers without having to pay for a separate server?
Is there a Python 3 library that's good for beginners (in networking - not Python) that can do this task?
Note 1: It is a turn based game so the processing does not have to be really fast.
Note 2: I have a basic understanding of sockets, servers, etc, I'm just not familiar enough with them to find what I'm looking for elsewhere.
Are you familiar with netcat? What do you mean by "(in networking - not Python)". The reason I ask if your familiar with netcat is because if you are sockets should not be too hard to program (I say that respectfully they can be weird at first glance). Your most likely going to have to open a port on your router to do this. Depending in the game will be the complexity of programming this. But basically this is what you want right.
TCP Server (Listening) (Your Friends House)
TCP Client (You)
TCL Client -> TCP Server
If your gonna be using a windows gui just use VNC Viewer: https://www.realvnc.com/download/viewer/ or TeamViewer: https://www.teamviewer.com/en/ or enable RDP.

Sending signal/text from Linux Machine to Labview in Window

Currently I'm developing a data acquisition program for my experiment in C++ from a Linux based machine (Ubuntu), I also have many VIs in Labview who is programmed in Windows to control the instruments of the experiment (motors, Signal Generator..). The purpose is to have a 2-way communication between 2 pc, the Linux will ask which VIs to be executed, and when it's finished, send back a signal to Linux machine.
My questions are:
Can I send a signal or a command to Labview in Windows from Linux (Terminal, and it can be implemented into my C code) and vice versa? How?
TCP Labview could be a solution? Or should I try to set the inter-PC "talking" through serial communication (which is easy to setup physically)?
The best (also the easiest) way is to implement TCP-based client-server communication (TCP will ensure data is lossless. When using other mechanisms like UDP or serial you should always make sure your commands are received correctly).
At LabVIEW site, you will have TCP listener (server) which will listen to commands from the Linux machine at your specified port.
Upon command reception, LabVIEW code can do the work and reply by the same TCP connection.
This is very good article about your question: https://decibel.ni.com/content/docs/DOC-9131
Their are several choices for communicating between C++ and LabVIEW. (As well as Linux / Windows).
If you are willing to run LabVIEW on your linux machine you can make use of several of the LabVIEW communication architectures. Here is NI's white paper.
http://www.ni.com/white-paper/12079/en/
Provides choices such as Shared Variable, Network Streams, Web Services, TCP/IP.
You can also take your LabVIEW code and compile it to a DLL and call it from C++ to make use of some of the above features. If not you are likely going to have to go to the TCP/IP route or web service.
I would recommend using TCP/IP, its pretty simple to implement on both sides.
If you are more familiar with serial protocols you can also use them to communicate.

Script for merging two SSH connections together?

I'm trying to write a bash script to merge 2 already-existing SSH connections.
For example, if I have an embedded device automatically creating an SSH connection to my server (from behind a firewall), how can I connect to that server in the middle, and jump into the already-existing connection from that embedded device?
I have looked into the possibility of using the server as a 'jump host', but it seems like I will need to reliably determine (and send SSH requests) to that embedded device?
I have also looked at having the embedded device create a 'screen' on the remote server and connect to that, but that just seems like it would be operating on the remote server.
I'm sorry if this is the wrong place to ask this, but I don't know where else to ask.
It sounds like your requirements are going to need either a uPNP solution or tunnelling solution to get through your firewall. The following link discusses reverse SSH tunneling as one part of this solution.
https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work

How to attach ttyS to screen and capture it simultaneously

For capturing ssh sessions I use "script" command: "script -c 'ssh user#host' outfile". But I have no idea how to capture sessions to remote hosts, that connected over com(serial) port.
screen script -c 'screen /dev/ttyS0 57600' file
ends immediately with empty log. Both 2 functions that implemented in screen is necessary: ability to switch between opened sessions and ability to perform i/o to /dev/ttyS. I started develop some tiny utility to redirect stdin/stdout to /dev/ttyS but now it's so buggy and doesn't work yet.
First off, a terminal program, like minicom (or good-ol cu), as suggested by Laszlo, is needed to communicate with the remote system. Once you can get such a program to work, then screen can be brought into the picture. Note that this also requires a getty running on the remote computer's serial port. If it's an old-fashioned serial port, you may also need a special null-modem cable.
Screen can be used with such a connection to be able to move access of the session across terminals. However, it cannot be used to spawn more than one session with the remote server. That's because the program running on the serial port (getty) only supports a single session. In this case, the screen runs on the local machine, and the terminal-program session running within screen connects to the remote server. So, it is possible to have multiple screens, but just not more than one connected to the remote server over a single serial port.
With all of that said, serial ports can be used to network two machines, assuming both support the same serial-line networking protocol. Networking eliminates these restrictions.
To open an interactive terminal session to a COM port (/dev/ttyS*), you probably want to use a terminal emulator software, like 'minicom'.

Resources