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/
Related
I want to build a DSR load balancer for an application I am writing. I wont go into the application because it is irrelevant for this discussion. My goal is to create a simple load balancer that does direct server response for TCP packets. The idea is to receive all packets at the load balancer, then using something like round robin, select a server from a list of available servers which are defined in some config file. The next step would be to alter the packer received and change the destination ip to be equal to the chosen backend server. Finally, the packet will be sent over to the backend server using normal system calls for sending packets. Theoretically the backend server should receive the packet, and send one back to the original requester, and then the requester can communicate directly with the backend server rather than going through the load balancer.
I am concerned that this design will not work as I expect it to. The main question is, what happens when computer A send a packet to IP Y, but receives a packet back in the same TCP stream from a computer at IP X? Will it continue to send packets to IP Y? Or will it switch over to IP X?
So it turns out this is possible, but only halfway so, and I will explain what I mean by this. I have three processes, one which is netcat, used to initiate an tcp request, a second process, the dsr-lb, which receives packets on a certain port, changes the destination ip to a backend server(passed in via command line arg), and forwards it off using raw sockets, and a third process which is a basic echo server. I got this working on a local setup. The local setup consists of netcat running on my desktop, and dsr-lb and echo servers running on two different linux VMs on the desktop as well. The path of the packets was like this:
nc -> dsr-lb -> echo -> nc
When I said it only half works, what I meant was that outgoing traffic has to always go through the dsr-lb, but returning traffic can go directly to the client. The client does not send further traffic directly to the backend server, but still goes through the dsr-lb. This makes sense since the client opened a socket to the dsr-lb ip, and internally still remembers this ip, regardless of where the packet came from.
The comment saying "if its from a different IP, it's not the same stream. tcp is connection-based" is incorrect. I read through the linux source code, specifically the receive tcp packet portion, and it turns out that linux uses source ip, source port, destination ip, and destination port to calculate a hash which is uses to find the socket that should receive the traffic. However, if no such socket matches the hash, it tries again using only the destination ip and destination port and that is how this "magic" works. I have no idea if this would work on a windows machine though.
One caveat to this answer is that I also spun up two remote VMs and tried the same experiment, and it did not work. I am guessing it worked while all the machines were on the same switch, but there might be a little more work to do to get it to work if it goes through different routers. I am still trying to figure this out, but from using tcpdump to analyze the traffic, for some reason the dsr-lb is forwarding to the wrong port on the echo server. I am not sure if something is corrupted, or if the checksum is wrong after changing the destination ip and some router along the way is dropping it or changing it somehow(I suspect this might be the case) but hopefully I can get it working over an actual network.
The theory should still hold though. The IP layer is basically a packet forwarding layer and routers should not care about the contents of the packets, they should just forward packets based on their routing tables, so changing the destination of the packet while leaving the source the same should result in the source receiving any answer. The fact that the linux kernel ultimately resolves packets to sockets just using destination ip and port means the only real roadblock to this working does not really exist.
Also, if anyone is wondering why bother doing this, it may be useful for a loadbalancer in front of websocket servers. Its not as great as a direct connection from client to websocket server, but it is better than a loadbalancer that handles both requests and responses, which makes it more scalable, and more able to run on less resources.
i have a measurement setup where i want to trigger an oscilloscope base on a network package arriving. I have good results for a few seconds but somewhere between 20s and 40s i get a wrong trigger. My research showed that this could come from the arp packages send from the device. I tried to disable the arp sending but then the whole network went down. Now i'm trying to find a solution where i change the rate at which the arp packets are send without success. So i'm asking you if you know a way to either disable or send as few arp request as possible.
For your information i'm working on a Linux machine. Any help would be appreciated.
I allready tried:
#ip link set arp off dev eth0 <--- results in network down
changing the values for:
/proc/sys/net/ipv4/neigh/default/gc_interval
/proc/sys/net/ipv4/neigh/default/gc_stale_time
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_timeout
with no success
Thx draufunddran
TL;DR: Disabling ARP on your machine will eventually cause other nodes on the network to stop sending packets to your machine (that is why your network appears to go down).
If you want to completely disable ARP packets on your network, you will need to manually program ARP tables on other nodes on your LAN (subnet) so that they know how to map your host's IP to a MAC address to send to on the LAN. This is a difficult thing to do if even possible since some nodes on your network may not offer the ability to program their ARP tables manually.
In wireshark I can see Membership Query, general IGMPv2 requests coming over and over from 0.0.0.0 source which suggests ( according to RFC ) machine that hasn't received address yet. My question is how in Linux environment I can find such machine. This query triggers many answers and causes significant network communication slowdown.
When a machine is connected to a network for the first time, it will try to find the DHCP servers in order to get an IP address configuration. Untill then, as you already said, it has no IP address and the only identifier it has is it's MAC address, which is used to keep a comunication alive while it negotiates with the DHCP server (during this period it does not have an IP address until the very last).
Answering your question, you'd find the machine you are looking for making use of the MAC address. If you are on a small network, a manual check (ifconfig) will do it but, if you are on a big one, you better check the ARP table of your switch(es) to have a better idea where it could be.
I'm an Automation Developer and lately I've taken it upon myself to control an IP Phone on my desk (Cisco 7940).
I have a third party application that can control the IP phone with SCCP (Skinny) packets. Through Wireshark, I see that the application will send 4 unique SCCP packets and then receives a TCP ACK message.
SCCP is not very well known, but it looks like this:
Ethernet( IP( TCP( SCCP( ))))
Using a Python packet builder: Scapy, I've been able to send the same 4 packets to the IP Phone, however I never get the ACK. In my packets, I have correctly set the sequence, port and acknowledge values in the TCP header. The ID field in the IP header is also correct.
The only thing I can imagine wrong is that it takes Python a little more than a full second to send the four packets. Whereas the application takes significantly less time. I've tried raising the priority for the Python shell with no luck.
Does anyone have an idea why I may not be receiving the ACK back?
This website may be helpful in debugging why on your machine you aren't seeing the traffic you expect, and taking steps to modify your environment to produce the desired output.
Normally, the Linux kernel takes care of setting up and sending and
receiving network traffic. It automatically sets appropriate header
values and even knows how to complete a TCP 3 way handshake. Uising
the kernel services in this way is using a "cooked" socket.
Scapy does not use these kernel services. It creates a "raw" socket. The
entire TCP/IP stack of the OS is circumvented. Because of this, Scapy
give us compete control over the traffic. Traffic to and from Scapy
will not be filtered by iptables. Also, we will have to take care of
the TCP 3 way handshake ourselves.
http://www.packetlevel.ch/html/scapy/scapy3way.html
I am trying to verify a new functionality added to the router kernel. So lets assume I added a filter,iptable and such. I have live traffic. I tried to use tcp dump and look into the packet header and see if the new values in the header are there but I am getting random traffic passing through.
I wonder if it is possible to have tcpdump send traffic and dump it so I have specific packets I sent ? or any other linux commands I can use to do the process. I have a destination port that has no traffic but I don't know how I can send to it and capture those packets. I did some reading on sendip and tcpdump and couldnt help myself.
Send packets, tcpdump it or something like that, verify the packet header has what I want and move on with my life.
I hope I was clear enough.