I am using a linux machine.
I want to set the number of TCP retransmits to zero. I am using below command to modify:
sudo sysctl -w net.ipv4.tcp_syn_retries=0
The above command dont work and gives me below error:
error: "Invalid argument" setting key "net.ipv4.tcp_syn_retries"
However, this command works -> sudo sysctl -w net.ipv4.tcp_syn_retries=1
According to the documentation -> man tcp :
tcp_syn_retries (integer; default: 5; since Linux 2.2)
The maximum number of times initial SYNs for an active TCP connection attempt will be retransmitted. This value should not
be higher than 255. The default value
is 5, which corresponds to approximately 180 seconds.
Does setting sudo sysctl -w net.ipv4.tcp_syn_retries=0 means disabling syn or syn retries. I am unclear after reading the documentation.
Related
I'm trying to use tcpdump to identify which IP address a particular person is coming from but I'm not seeing the HTTP commands as various web site show. I've used the following to set up tcpdump:
nohup tcpdump -i eth0 -P in -nn -n -tttt -w /home/tcpdump/port80.log -C 100 -W 50 "port 80" > /home/tcpdump/nohup.log 2>&1 &
And I'm peridoically checking the file using
tcpdump -r port80.log00 -n -nn -A
I'm connecting to the following URL from a web browser:
http://10.10.0.50?test
And I was expecting to see a bunch of HTTP "GET" commands but tcpdump doesn't seem to be showing me the incoming messages. Instead I just get something like
16:21:35.708250 IP 10.10.0.222.55924 > 10.10.0.50.80: Flags [S], seq 1869638484, win 8192, options [mss 1340,nop,nop,sackOK], length 0
E..0#H#....\
..
.2.t.PopkT....p. ........<....
Looking at other info on using tcpdump for HTTP logging I'm should be seeing the "GET" command after the first few bytes of garbage. There's no actual web server running - I'm only interested in seeing the incoming request as a test, hence the "?test" on the end to help me search the logs for the right thing. I don't see that that's the issue tho'.
Any help very gratefully received.
Environment:
Unix client and unix server.
Tool used : curl.
Client/Server should ignore the time wait time (2 *MSL ) when establishing connection.
This is done by executing the following commands :
sysctl net.ipv4.tcp_tw_reuse=1
sysctl net.ipv4.tcp_tw_recycle=1
Local port must be specified so that it can re-used.
Start the connection.
Example : while [ 1 ]; do curl --local-port 9056 192.168.40.2; sleep 30; done
I am still seeing the error even though it should have ignored time wait period.
Any idea why this is happening?
I noticed a strange behaviour working with netcat and UDP. I start an instance (instance 1) of netcat that listens on a UDP port:
nc -lu -p 10000
So i launch another instance of netcat (instance 2) and try to send datagrams to my process:
nc -u 127.0.0.1 10000
I see the datagrams. But if i close instance 2 and relaunch again netcat (instance 3):
nc -u 127.0.0.1 10000
i can't see datagrams on instance 1's terminal. Obsiously the operating system assigns a different UDP source port at the instance 3 respect to instance 2 and the problem is there: if i use the same instance'2 source port (example 50000):
nc -u -p 50000 127.0.0.1 10000
again the instance 1 of netcat receives the datagrams. UDP is a connection less protocol so, why? Is this a standard netcat behaviour?
When nc is listening to a UDP socket, it 'locks on' to the source port and source IP of the first packet it receives. Check out this trace:
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(10000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
recvfrom(3, "f\n", 2048, MSG_PEEK, {sa_family=AF_INET, sin_port=htons(52832), sin_addr=inet_addr("127.0.0.1")}, [16]) = 2
connect(3, {sa_family=AF_INET, sin_port=htons(52832), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
Here you can see that it created a UDP socket, set it for address reuse, and bound it to port 10,000. As soon as it received its first datagram (from port 52,832), it issued a connect system call 'connecting' it to the 127.0.0.1:52,832. For UDP, a connect rejects all packets that don't match the IP and port in the connect.
Use the -k option:
nc -l -u -k 0.0.0.0 10000
-k means keep-alive, that netcat keeps listening after each connection
-u means UDP
-l listening on port 10000
Having given up on netcat on my OS version this is pretty short and gets the job done:
#!/usr/bin/ruby
# Receive UDP packets bound for a port and output them
require 'socket'
require 'yaml'
unless ARGV.count == 2
puts "Usage: #{$0} listen_ip port_number"
exit(1)
end
listen_ip = ARGV[0]
port = ARGV[1].to_i
u1 = UDPSocket.new
u1.bind(listen_ip, port)
while true
mesg, addr = u1.recvfrom(100000)
puts mesg
end
As the accepted answer explains, ncat appears not to support --keep-open with the UDP protocol. However, the error message which it prints hints at a workaround:
Ncat: UDP mode does not support the -k or --keep-open options, except with --exec or --sh-exec. QUITTING.
Simply adding --exec /bin/cat allows --keep-open to be used. Both input and output will be connected to /bin/cat, with the effect of turning it an "echo server" because whatever the client sends will be copied back to it.
To do something more useful with the input, we can use the shell's redirection operators (thus requiring --sh-exec instead of --exec). To see the data on the terminal, this works:
ncat -k -l -u -p 12345 --sh-exec "cat > /proc/$$/fd/1"
Caveat: the above example sends data to the stdout of ncat's parent shell, which could be confusing if combined with additional redirections. To simply append all output to a file is more straightforward:
ncat -k -l -u -p 12345 --sh-exec "cat >> ncat.out"
OK, we all know how to use PING to test connectivity to an IP address. What I need to do is something similar but test if my outbound request to a given IP Address as well as a specif port (in the present case 1775) is successful. The test should be performed preferably from the command prompt.
Here is a small site I made allowing to test any outgoing port. The server listens on all TCP ports available.
http://portquiz.net
telnet portquiz.net XXXX
If there is a server running on the target IP/port, you could use Telnet. Any response other than "can't connect" would indicate that you were able to connect.
To automate the awesome service portquiz.net, I did write a bash script :
NB_CONNECTION=10
PORT_START=1
PORT_END=1000
for (( i=$PORT_START; i<=$PORT_END; i=i+NB_CONNECTION ))
do
iEnd=$((i + NB_CONNECTION))
for (( j=$i; j<$iEnd; j++ ))
do
#(curl --connect-timeout 1 "portquiz.net:$j" &> /dev/null && echo "> $j") &
(nc -w 1 -z portquiz.net "$j" &> /dev/null && echo "> $j") &
done
wait
done
If you're testing TCP/IP, a cheap way to test remote addr/port is to telnet to it and see if it connects. For protocols like HTTP (port 80), you can even type HTTP commands and get HTTP responses.
eg
Command IP Port
Telnet 192.168.1.1 80
The fastest / most efficient way I found to to this is with nmap and portquiz.net described here: http://thomasmullaly.com/2013/04/13/outgoing-port-tester/ This scans to top 1000 most used ports:
# nmap -Pn --top-ports 1000 portquiz.net
Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-02 22:28 CDT
Nmap scan report for portquiz.net (178.33.250.62)
Host is up (0.072s latency).
rDNS record for 178.33.250.62: electron.positon.org
Not shown: 996 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
8080/tcp open http-proxy
Nmap done: 1 IP address (1 host up) scanned in 4.78 seconds
To scan them all (took 6 sec instead of 5):
# nmap -Pn -p1-65535 portquiz.net
The bash script example of #benjarobin for testing a sequence of ports did not work for me so I created this minimal not-really-one-line (command-line) example which writes the output of the open ports from a sequence of 1-65535 (all applicable communication ports) to a local file and suppresses all other output:
for p in $(seq 1 65535); do curl -s --connect-timeout 1 portquiz.net:$p >> ports.txt; done
Unfortunately, this takes 18.2 hours to run, because the minimum amount of connection timeout allowed integer seconds by my older version of curl is 1. If you have a curl version >=7.32.0 (type "curl -V"), you might try smaller decimal values, depending on how fast you can connect to the service. Or try a smaller port range to minimise the duration.
Furthermore, it will append to the output file ports.txt so if run multiple times, you might want to remove the file first.
My Perl script gets stuck with an exit status when trying to use the ping command.
According to this website:
If ping does not receive any reply packets at all it will exit with code 1. If a packet count and deadline are both specified, and fewer than count packets are received by the time the deadline has arrived, it will also exit with code 1. On other error it exits with code 2. Otherwise it exits with code 0. This makes it possible to use the exit code to see if a host is alive or not.
To list the results:
Success: code 0
No reply: code 1
Other errors: code 2
Note that the page I link to says "Linux/Unix ping command", but other systems, or perhaps even variants of Linux and Unix, might vary this value.
If possible, I would test on the system in question to make sure you have the right ones.
It's worth doing some testing on this on your OS. e.g on OSX
Resolvable host which is up
ping -c 1 google.com ; echo $?
Replies:
PING google.com (173.194.38.14): 56 data bytes
64 bytes from 173.194.38.14: icmp_seq=0 ttl=51 time=16.878 ms
--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.878/16.878/16.878/0.000 ms
Returns
0
Resolvable host which is down/does not respond to ping
ping -c 1 localhost ; echo $?
Replies:
PING stuart-woodward.local (127.0.0.1): 56 data bytes
--- stuart-woodward.local ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
Returns:
2
Non Resolvable host
ping -c 1 sdhjfjsd ; echo $?
Replies:
ping: cannot resolve sdhjfjsd: Unknown host
Returns:
68
The ping utility returns an exit
status of zero if at least one
response was heard from the specified
host; a status of two if the
transmission was successful but no
responses were received; or another
value (from ) if an error
occurred.
http://www.manpagez.com/man/8/ping
The actual return values may depend on your system.
Successful connection will always return code 0, whilst failed connections will always return code 1 and above.
To test this out, try this snippet
#!/bin/bash
light_red='\e[1;91m%s\e[0m\n'
light_green='\e[1;92m%s\e[0m\n'
ping -c 4 -q google.comz
if [ "$?" -eq 0 ]; then
printf "$light_green" "[ CONNECTION AVAILABLE ]"
else
printf "$light_red" "[ HOST DISCONNECTED ]"
fi
You should also take into account that if the ping for example receives a 'network unreachable' icmp reply, it will be counted as reply an thus returns success status 0 (tested with cygwin ping on windows). So not really useful for testing if a host is alive and IMO a bug.
Try man ping from the command line. The return values are listed near the bottom.