To avoid application-related issues and just do a bare-bones test of whether or not a port is open, use netcat or socat. On the server end, turn off the application that should be listening on port 9092, then:
Start listening on the server side:
netcat -l -p 9092 (newer versions of netcat)
netcat -l 9092 (older versions)
Attempt to connect to the port from the client on the other side of the firewall:
nc IPADDRESS 9092
If everything is working, anything you type on either end should be mirrored on the other end.
Start listening on the server side:
socat TCP4-LISTEN:9092,reuseaddr,fork gopen:/tmp/capture,seek-end=0,append
Now send some text from the client end to the listener:
date | socat STDIO tcp:localhost:9092
In this example, the client is on the same machine, replace "localhost" with an IP or DNS if not. All text sent from the client side will be appended to the file /tmp/capture.
Much *nix software will obey the proxy environment variables:
for a squid proxy on IP 220.127.116.11, for instance. (Use "unset" to turn these environment variables off later.) You can then test with and without the proxy thusly, for example:
w3m -no-proxy http://google.com/
Or you can test directly with telnet:
telnet 18.104.22.168 3128
which in the case of squid will result in following output:
Escape character is '^]'.
And then enter the URL you wish to access over the proxy:
GET http://www.google.com/ HTTP/1.1
followed by this line:
followed by two returns, and the site html will be dumped in your terminal.
On one side, with port 5001 open, start the server:
On the other side, start a bi-directional test:
iperf -c IP-of-server -d
Of course, to test a TCP port, most have probably seen telnet in action:
Telnet, however, only talks TCP. To test a UDP port use netcat:
netstat -tulpn | grep ls -l /proc/ /exe
I have been hearing buzz about the "screen" utility for some time, and having tried it, I am now a serious devotee. Wish I had looked at it earlier....
Screen basically gives access and control of multiple terminal sessions in one open SSH session to a server. Ie. instead of using SSH to login to a server from multiple terminals, just use one terminal and invoke "screen" once logged in.
Screen becomes useful with only a very short list of keystrokes:
Ctrl-a c - create a new "screen"
Ctrl-a n - cycle to the next "screen"
Ctrl-a p - cycle to the previous "screen"
Ctrl-a d - detach from screen program, which continues to run in background
Ctrl-a [ - permit scrolling through the terminal's history buffer
Ctrl-c - exit scroll mode and return to command mode
If you only have two or three "screens" open, that is about all you really need.
Killer Feature #1: No More Clobbered SSH Sessions
If you detach from screen and logout, or are forcibly detached by an interrupted SSH session, screen continues to run on the server in the background. That means, for instance, that you can allow a big file transfer to continue on the server without needing an open SSH session. Or, in the case of a network problem resulting in an interrupted SSH session, just log back into the server, and enter:
screen -r -d
to be returned to all your screen session, with all your open terminals, EXACTLY THE WAY YOU LEFT THEM. No more having to navigate back to where you were before. Absolutely indispensable in the crappy excuse for a network we have here in China.
Killer Feature #2: Terminal Sharing!!
Sharing your terminal (both input and output) is simple with screen, as long as both people can SSH into the server and su to the same user:
First one person starts screen, then the other person su's to the same username on the server and attaches to the other screen session as follows:
And now both people are looking at exactly the same screen / terminal session, and both can type into that terminal. Sometimes when the second person tries to attach, there is an error message like the following:
Cannot open your terminal '/dev/pts/3' - please check.
To fix, just chmod the file /dev/pts/3 to make permissions more permissive.