In packet delivery from router to destination how ping commands work to find latencies between them
Related
I have a server in AWS-East-1 (N. Virginia) and I am trying to ping www.binance.com whose server is located in AWS Tokyo.
Command: ping www.binance.com
I get ping times of 0.5ms which is not true. Possibly, the ping is returning from some nearby router and theoretically even at the speed of light, the return trip should take atleast 75ms.
How do I measure the correct ping latency from my Linux terminal?
Assuming you need to make this test to check performance of application or network.......
Maybe, you can use other approach:
curl -o /dev/null -s -w '%{time_connect}\n' https://www.binance.com
It will return the time_connect so maybe it can help you in your analysis.
I recommend you to measure a round trip delay. It is the delay between the time when your network node request packet is sent and a time when the response packet from remote server arrives back to you. It can be measured by the Wireshark network analyzer. It analyzes a real traffic. The results are more accurate then from the ICMP protocol (ping) tests.
Wireshark usage
Ensure you have not opened any connection to your destination server (e.g. www.binance.com). Check all tabs in your web browser(s).
Find out the IP address of your destination server: dig +short www.binance.com and note all found addresses.
Install the Wireshark application if it is not installed.
Start the Wireshark, select correct interface on which the network data will be captured and start the capturing.
Open the IP address of page you will measure e.g. 65.9.96.71 in the browser. Refresh the page. It is not problem if error is displayed in browser.
Stop the capturing in Wireshark.
Put a filter string to the display filter field of the Wireshark. (See below for filter examples.) Press Enter. Only packets which have selected IP address will be displayed.
Watch the packet times in second column. Calculate the delay between the request packet and the response one.
Wireshark display filters (each line is one example):
ip.addr==65.9.96.71
ip.addr==65.9.96.30 and tcp.port==80
ip.addr==65.9.96.30 and tcp.port==443
Note:
The Wireshark installation in Linux requires some special steps. Confirm you agree that the Wireshark can be used by all users in system. Add your user to the wireshark group and re-login to apply new user setting.
usermod -aG wireshark <your_user>
Additional information
You can trace the network path between your client and remote server by traceroute. It shows you what nodes (routers) are there.
Verify in which country the destination IP address is situated. Use some IP Whois web page to get details. https://ipwhois.io/
I was looking into raw sockets. so I created one raw socket client and other one is server. on two different computers. I am using ISP provided router. so I sent spoofed packet (with iphdr struct's saddr of different computer on same network) from client but when the packet received at the server the source ip in packet's ip header was correct (the real sender address=client address) plus the source port and destination port of tcphdr were something different too (which really didnt make sense). So I assumed that my ISP provided router is doing something funny -- OR I am completely wrong correct if this is a normal ip protocol. if I am correct then what steps should i take to configure my router so it does not mess up with tcp and ip headers of incoming packets plus the sync=1 at sender's end became sync=0 of tcphdr. I am using local IPs plus I am trying to implement tcp using raw socket server. I have configured iptables on server as well with sync allowed on my bounded port
iptables -I INPUT -p tcp --dport xxxx --syn -j ACCEPT
WHat settings do I need to do on server in iptables so my socket incoming packets wont be dropped nor any header be touched so I can get all packets required for tcp to keep coming in. plus what setting do I need to do on router so,if its cause problem then, it wont
Update 1:
after spending some time to the problem I found that one cause could be my kernel tcp stack dropping the incoming sync packets. so I looked around and found that in the tcp stack there is work done to make this happening. So I changed the sysctl.conf in /etc to allow sync packets to come in through by adding or uncommenting this line
net.ipv4.tcp_syncookies=1
Then I rebooted the system but still no difference. is it because somehow I have to reload my sysctl.conf file. if this is the case or any related case then please fill in.
Update 2
I have reloaded sysctl.conf after allowing syn packets and now I am getting syn packets from client application. but the destination port different. also along with syn=1, ack=1 is also coming in same packet. is this also something kernel is doing. please explain. as long as I know this is not how tcp works (tcp handshake) and I am connecting from client using stream socket
In a linux system, I use scapy to send a high frequency UDP ping. For example: each 20 milliseconds, send a UDP packet; a total of 100. But I can only get the first few ICMP port unreachable answer.
pkt = IP(dst=dst)/UDP(dport=RandShort())
ans,_ = sr(pkt*100, inter=0.02, timeout=3)
I tried to use tcpdump to capture packet and found that all UDP packets have been sent to the target machine, but only a few ICMP packet came back to the source machine. What would cause this?
If I use ICMP pingļ¼this does not happen.
I guess:
may be caused by the target machine's system kernel parameter which process icmp packet
may be caused by the icmp packet routing switch strategies.
The rate of ICMP packets is hard limited by the kernel to prevent DDOS attacks. Usually to only 1 packet per second. Almost impossible to get anything faster than that in any external (internet) router. Example
My Linux (Debian) server has eth0 and eth1, and both are on the same subnet.
It receives packets from both interfaces, but it only replies from eth0.
Packets that are sent to eth1 are replied from eth0, and the reply has eth0's src mac and eth1's src IP.
I verified this by sending a ping to eth1 while running tcpdump on the Linux server.
This is a problem because:
Since no packets are sent with a source mac of eth1 (with the exception of the initial arp), the switch forgets the eth1 mac. Then, every packet with the destination mac of eth1 that is received by the switch is broadcasted across the network, flooding it which makes us sad.
I want:
My Linux server to send packets out from both eth0 and eth1. I think the nicest solution is that for each packet we get, we reply from the same interface. Another way to put it is that I want to bind each interface to its IP and MAC - so that it will only send packets from these addresses.
More details:
My Linux server is an ISCSI Target communicating with an ESX which is an ISCSI Initiator - though a Cisco switch. The switch forgets MACs after 5 minutes, and the ESX probably remembers them for 20 minutes (as discussed here and here). So while the ESX remembers the mac of the Linux, the ESX keeps sending ISCSI requests which flood the network, while my server sends ISCSI replies through only one of the interfaces.
This isn't what you asked for, but if you just set up a cron job on the box that did
ping -c 1 -I eth1 <address of eth1's default gateway>
every minute, then you would have at least one packet per minute leaving eth1 with eth1's MAC address on it. -I tells ping to bind to a specific interface, so it won't use eth0 even if that's the preferred route.
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)