I'm trying to create some test network traffic by sending TCP traffic using netcat.
The issue is that the netcat command to receive TCP data doesn't end on its own, which makes perfect sense.
I'm wondering how I can have a script that continues running to the send portion of the TCP traffic. Something similar to:
#!/bin/bash
#Prepare to receive traffic
nc -vv -l -p 5000 > receiveData.txt
#Send traffic
nc -nvv localhost 5000 < sendData.txt
Obviously the script will never get to the #Send traffic line because the receive traffic never ends. I've been looking at methods for running functions in bash asynchronously, but nothing I've read seems to solve this problem.
How about just running receive traffic process in the background so that the other commands can be executed to?
# Prepare to receive traffic
# Running this process in the background so that the sending TCP traffic
# happens
nc -vv -l -p 5000 > receiveData.txt &
#Send traffic
nc -nvv localhost 5000 < sendData.txt
Related
So right now I have a server that is pinging an api and writes to stdout. I pipe that to nc as such.
node server.js | nc -lk 9999
I then have a job that listens to that and outputs 5 second snapshots of the data.
My question is that when I try to do that in multiple sessions with multiple server.js programs eg. server1.js, server2.js which all hit different parts of the api and pipe them all to port 9999. Only the first program gets picked up by the snapshot job. How do I pipe multiple outputs to:
nc -lk 9999
such that they all get handled as if it's the output of one program?
If you execute multiple times that command, it simply won't work. You cannot listen with several instances of netcat on the same port. You should get a nc: Address already in use error.
What you can do is something like:
mkfifo queue
nc -lk 9999 < queue
node server.js | cat > queue
Btw I did a nice and fully working Netcat porting in Node.js: https://github.com/roccomuso/netcat
This easily address the issue you're encountering, because you can implement the whole logic in JS without using the native nc bin or pipe data on the stdin.
I am new to writing script and not sure whether I am correct in writing such script for tcpdump to collect pcap info.
tcpdump -s 0 port ftp or ssh or http or https -i eth0 -w mycap.pcap
#run the tcpdump and store all the info in mycap.pcap
sudo kill -2 #for exit purpose
This enables me to run tcpdump which is good, however, I wish to stop this (due to the space for mycap.pcap meet the max capacity of 3GB per file) automatically via the same script and run again but this time round, I will store it in another file (eg. mycap1.pcap)
Then the cycle goes again until I stop the process by pressing crtl+c
Can this be done?
You don't need to write a script for that.
tcpdump -C <filesize> -s 0 port ftp or ssh or http or https -i eth0 -w mycap.pcap
Have a look at the man-page for tcpdump.
I want to combine "chat" and "nc" on linux, so I will create a tiny udp server that responds on a specific request and sends back an answer.
In fact I want to redirect the stdout of "nc" to the stdin of "chat" and vice versa. My first attempt was:
nc -w 3000 -u -n -l -p 30000 >&1111 <2222 &
chat -V 'request' 'answer' >&2222 <1111
But it didn't work.
use socat instead of netcat. Something like this :
socat UDP-LISTEN:5555 EXEC:"chat -sv ping pong",pty
To test it, you can open another terminal, and use socat to bridge stdio and an UDP socket :
socat - UDP:localhost:5555
Type ping, and you will get pong !
I am running CentOS 5 with csf firewall. I'm running a program that can't connect to another server (using some port that is blocked by csf I presume). Where is the log file for 'ports'?
Netstat is the command to use to get ports and network activity. To diagonise server processes I usually use:
netstat -tln
This yields port numbers in tcp mode listening. To identify associated processes you can also use -p to grab the pid. Here is the IANA ports list.
I found my answer right after searching a few more threads.
# tail -f /var/log/messages
Shows the UDP message but not the port.... Hmm....
I have a remote Music Player Daemon(MPD) server running on a linux machine. I have a client listening to this stream on another linux machine.
When the MPD server is asked to pause or stop the stream, it disconnects all clients connected on the TCP port. Consequently, when the server starts streaming again, the clients have to be manually reconnected.
I want to write a program that will monitor the TCP port for a server accepting connections, and then automatically restart the clients. Can I do better than running connect() and sleep() in a loop? Are there any command-line utilities to do this?
I can run the client on the machine running the MPD server, if it will help. The following will tell me if a process is listening on a local port, but they do not block if a process isn't, so I still need to wrap them in a loop.
$ sudo fuser -n tcp 8000
8000/tcp: 9677
$ sudo netstat -nlp | grep 8000
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 9677/mpd
I can try any solution that does not involve changing the behaviour of the MPD server.
There is always the possibility of writing a relay server that proxies for MPD.
It sits there listening on a different port for your clients and makes connections to MPD in their stead. When MPD disconnects, the relay just attempts to reconnect every few seconds without disconnecting its clients.
Here you go:
echo -n "" | nc -q 0 localhost 8000 && echo "made a connection" || echo "server was down"
echo -n "" puts an EOF immediately on stdin; nc -q 0 returns immediately after seeing that EOF on stdin. nc (netcat) tries to make a connection to localhost on port 8000. If it connects successfully, then it returns a successful error code and we echo "made a connection"; otherwise, if the connection was refused, we echo "server was down".
If you want to test it out, then in another terminal run
nc -lvvp 8000
which will start an instance of netcat listening on port 8000, with verbose output. In your other terminal, run the first command. The first time you run it, it will say made a connection. Then the server/listener will close, so the next time you run it, it will say server was down.