Redirect modified output of a program back to its input - bash

For fun, I want to type something in Bash that will connect to an IRC server and automatically respond to PING messages
For example, I have the following output from telnet
Connected to irc.example.com.
Escape character is '^]'.
PING :12341234
If I pipe this to grep and then sed, I can easily turn this output into PONG :12341234, but how do I send it back to the standard input stream of telnet?
Additionally, I'd like to still being to manually send input using the keyboard

What you're trying to do is known as an "echo server". It is fairly easy to do with netcat and it's variants (nc or netcat, ncat, etc.).
For example:
ncat -l 2000 --keep-open --exec "/bin/cat"
In another shell
telnet localhost 2000
Whatever you send will be replied by ncat.

Related

Bash script to write to unix socket and then read a response but ONLY AFTER the welcome message

I am connecting to a server that initiates an SSH tunnel for me so I can connect to a remote device.
I can do an interactive socat connexion and manually issue commands like this:
Connected to soundwave server v131 (welcome message)
tunnel r 7 localhost:22 (my command)
Attempting to initiate a tunnel session ID [55] on local port 30054. (response)
The text in parenthesis is just my notes. They aren't actually part of the commands or responses.
I know I can send a message to a unix socket using socat
echo "tunnel r 7 localhost:22" | socat UNIX-CONNECT:data/files/monitor.socket STDOUT
And I saw some posts about being able to write a command and read a command with socat.
But the software has limitations that it only listens for commands until after the welcome message is issued.
So, is there a way with socat, nc, or any other tool to connect to a unix socket automatically, read the welcome message, write the tunnel command, and then parse the response to get the port so I can open up an SSH session?
Thanks so much.

ncat on windows: -e option forwards input but does not forward output

I start ncat (on Windows 10) with
ncat -vvlp 1234 -e code.exe
and then connect with a second instance of ncat to the first instance
(ncat 127.0.0.1 1234).
code.exe is a C program written by me that can be controlled over stdin.
Everything I send via the second ncat gets forwarded to the stdin of code.exe. I know this because I can see code.exe create a folder after sending the command to do so. But the output is not send back until code.exe closes itself.
Why is that — and how can I fix it?
Ok I found a solution to my problem. I disabled buffering of stdout by using
setbuf(stdout, NULL);
at the start of my C program.

Script for sending a header to netcat

I work with a protocol that's easy to use simply with netcat. The protocol starts with a login message, so I thought I could bang out a little script which pipes the login message before stdin to netcat for me.
I was able to get close, but there's one problem I can't figure out. The following script works, in that it sends the login message and allows me to interact with netcat. But if netcat exits (because the server side closed the connection), the script just hangs there (presumably because cat is still reading stdin even though no one is reading stdout any more).
( echo "${LOGIN}"; cat ) | nc ${HOST} ${PORT}
It's a tricky problem, and you're right about the cause. Processes don't get a NOPIPE error and SIGPIPE until they actually try to write to the pipe.
If nothing else, you can use the interaction scripting tool expect:
expect <(echo '
spawn nc google.com 80
send "GET / HTTP/1.0\n"
send "Host: www.google.com\n"
interact
')
This will run nc, send some HTTP headers, and then gives control to you. When nc exits, so does the command.

How can I tell what host a packet comes from using netcat?

I'm trying to write a server using netcat and bash. to recieve asynchronous packets, i'm using the command
netcat -lu 6791
How can I tell what host a packet came from? Is there a better tool i should be using then netcat (socat maybe?)
wireshark (GUI tool), tshark (text-based version of wireshark), and/or tcpdump (very similar to tshark, at least until you start messing with filtering out specific packets or searching for certain patterns or anything more complex) come immediately to mind...
#twalberg's suggestion,
netcat -vv -lu -p 6791 worked.

How to connect stdin of a list of commands (with pipes) to one of those commands

I need to give the user ability to send/receive messages over the network (using netcat) while the connection is stablished (the user, in this case, is using nc as client). The problem is that I need to send a line before user starts interacting. My first attempt was:
echo 'my first line' | nc server port
The problem with this approach is that nc closes the connection when echo finishes its execution, so the user can't send commands via stdin because the shell is given back to him (and also the answer from server is not received because it delays some seconds to start answering and, as nc closes the connection, the answer is never received by the user).
I also tried grouping commands:
{ echo 'my first line'; cat -; } | nc server port
It works almost the way I need, but if server closes the connection, it will wait until I press <ENTER> to give me the shell again. I need to get the shell back when the server closes the connection (in this case, the client - my nc command - will never closes the connection, except if I press Ctrl+C).
I also tried named pipes, without success.
Do you have any tip on how to do it?
Note: I'm using openbsd-netcat.
You probably want to look into expect(1).
It is cat that wait for the 'enter'.
You may write a script execute after nc to kill the cat and it will return to shell automatically.
You can try this to see if it works for you.
perl -e "\$|=1;print \"my first line\\n\" ; while (<STDIN>) {print;}" | nc server port
This one should produce the behaviour you want:
echo "Here is your MOTD." | nc server port ; nc server port
I would suggest you use cat << EOF, but I think it will not work as you expect.
I don't know how you can send EOF when the connection is closed.

Resources