This site has no ads. To help with hosting, crypto donations are accepted:
Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs
Sun, 27 Dec 2015
/Admin/commandLine/network:
Port/Firewall Testing with Netcat and Socat
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:
FOR NETCAT:
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.
FOR SOCAT:
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.
posted at: 02:44 | path: /Admin/commandLine/network | permanent link to this entry
Thu, 08 Jan 2015
/Admin/commandLine/network:
Configuring and Testing Proxies on the Command Line
Much *nix software will obey the proxy environment variables:
export http_proxy=http://1.2.3.4:3128/
export https_proxy=http://1.2.3.4:3128/
for a squid proxy on IP 1.2.3.4, for instance.
(Use "unset" to turn these environment variables off later.)
You can then test with and without the proxy thusly, for example:
w3m http://google.com/
w3m -no-proxy http://google.com/
Or you can test directly with telnet:
telnet 1.2.3.4 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:
host:www.google.com
followed by two returns, and the site html will be dumped in your terminal.
posted at: 04:16 | path: /Admin/commandLine/network | permanent link to this entry
Mon, 18 Feb 2013
/Admin/commandLine/network:
Bandwidth Measurement with iPerf
On one side, with port 5001 open, start the server:
iperf -s
On the other side, start a bi-directional test:
iperf -c IP-of-server -d
posted at: 02:27 | path: /Admin/commandLine/network | permanent link to this entry
Tue, 19 Jun 2012
/Admin/commandLine/network:
Port Testing
Of course, to test a TCP port, most have probably seen telnet in action:
<![CDATA[
telnet <IP> <Port#>
]]>
Telnet, however, only talks TCP. To test a UDP port use netcat:
<![CDATA[
nc -u <IP> <Port#>
]]>
posted at: 23:07 | path: /Admin/commandLine/network | permanent link to this entry
Sat, 07 May 2011
/Admin/commandLine/network:
Find What is Listening on a Port
<![CDATA[
netstat -tulpn | grep <port#>
ls -l /proc/<PID>/exe
]]>
posted at: 00:13 | path: /Admin/commandLine/network | permanent link to this entry
Wed, 01 Sep 2010
/Admin/commandLine/network:
Screen: An Easy Way to Open Multiple Terminals on a Linux Server
I have been hearing buzz about the "screen"[1] 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:
screen -x
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.
[1] http://savannah.gnu.org/projects/screen
posted at: 01:09 | path: /Admin/commandLine/network | permanent link to this entry
