2

I'm aware that this is an unusual question, but it seems the people here are very likely the ones who can help. I'm trying to debug with my ISP why I'm having extreme lags during gameplay.

Question: What is a good way to analyse packet-runtime and -loss that gives me more detailed information about where the bottleneck in the connection is? Is there an easy way to reproduce the traffic artificially to some degree without actually playing the game?

Here is my situation:

  • My ISP provides my connection over a large wireless network with several access points over some 10km before reaching the main cable. It has always been this way and in the past, it proved to be extremely reliable. Due to changes in the hardware or other setup changes of my ISP, the gameplay quality dropped several months ago. My ISP is very helpful and tries to find and fix the source of the problems.
  • I have in general a very good ping and when I play, the in-game information always shows a good ping of 20-30ms.
  • A feature of Battlefield is that it shows warning symbols when the frame-rate drops, the connection turnaround time is bad or packets got lost. The situation that repeats is that I can play about 10-60seconds without any warning symbol and then I experience a severe packet loss where I have lags and BF shows me all kinds of connection warnings. After that, I can play again for some seconds before I see this behaviour again.

I'm exclusively working on Linux and I'm somewhat comfortable with ping, traceroute, nmap, and other network tools. I know the high-ports that BF uses, I can find out the used packet-sizes and of course I can extract IP's from game-servers. What is a good way to start tracking this issue down so that I can hopefully provoke the packet-loss artificially while my ISP debugs what happens in his network?

Analysis

I have installed WireShark as kindly suggested by moonpoint and captured some minutes of laggy gameplay. In a first analysis, I concentrated on the packets that are coming from the game-server. I filtered all UDP packets that are coming from the server to my IP and adjusted the time to see the relative time between those packets. After sorting there were about 20 packets that took between 650 ms and 1300 ms which I suspect are the ones where I'm jumping half over the map. Between most of the other packets have almost exactly the runtime time that I see as "Ping" inside the game of about 30 ms.

After marking all the critical packets, I cleared the filter and looked at all the traffic to see if I can find some pattern of what is on with all packets around the critical ones. What I found is that there are two situations. Note that 94.250.208.153 is the game-server and the blue highlight is the critical UDP game package:

First, about 10-15 packets before the critical one there is a mystical SSDP M-Search packet coming from a MAC address:

img

The second situation is that the critical packet is preceded (or sometimes surrounded) by a TCP Retransmission mostly to a Google server:

enter image description here

Are there any further steps I could take from my side? Can someone tell me how I can investigate in the mystical SSDP packet?

4
  • First thing I would check is to ensure your up and down-stream both are not congested. A download will stall if upload does and visa versa. A download is usually fast enough, but the upload could be a problem. Ping will not detect upload problems other than that it detects a failure, but not the cause. Sites like speedtest.net give a graph while they do the test. Is the upload stable? Do you have other programs running that could use the upload?
    – LPChip
    May 26, 2017 at 13:13
  • @LPChip Thanks for the suggestion, but this is one thing I tested already. I have pretty stable up- and down-stream.
    – halirutan
    May 27, 2017 at 4:57
  • At the moment of writing that comment, which was before you edited your post, it was not written in your question, otherwise I would not have suggested it. Rule of Thumb, to avoid people asking you to do things you already have done, mention them in your question. :)
    – LPChip
    May 27, 2017 at 11:01
  • @LPChip No worries. My edit was only possible because of moonpoint's answer :)
    – halirutan
    May 27, 2017 at 11:54

1 Answer 1

1

MTR, which combines functionality found in ping and traceroute, can also be a useful tool for determining the point or points along a network path where packet loss is occurring or where jitter is high (example).

You could also use the free and open source Wireshark packet analyzer to troubleshoot the problem, but being able to understand the information it provides requires familiarity with how the underlying Internet protocols, such as TCP/IP, work. There are courses and tutorials on its usage online. Though learning how to use it effectively may take a fair amount of time, once you learn how to use a tool such as Wireshark, you will be able to more easily troubleshoot all sorts of problems involving network connectivity.

If you are unfamiliar with Wireshark, on YouTube, there is WireShark Tutorial for Beginners and Wireshark 101: How to Wireshark, Haktip 115; many others can be found by searching on the terms "Wireshark tutorial". Websites with tutorials include Quick and dirty Wireshark tutorial, How to Use Wireshark to Capture, Filter and Inspect Packets, and Wireshark Tutorial, which is a PDF file created by Professor Angelos Stavrou in the Computer Science Department of George Mason University. There are also online courses available on how to use Wireshark.

With Wireshark, or tcpdump, a command line packet capture tool available for Linux, OS X and Microsoft Windows (WinDump) systems, you can capture the packets flowing from and to your system when the problem occurs so that you can analyze the data yourself later or in real-time, or, since both tools can save the data you've captured as a pcap file, you can provide the data to your ISP's network support staff, since their personnel may be familiar with interpreting such data, as pcap files are a common method to exchange data on a network issue among network engineers when debugging a problem.

Wireshark will capture all data on a network interface, but since you know the network port numbers and IP addresses associated with the Battlefield game servers, you can use a Wireshark filter to filter on port number(s) and/or IP address.

Update:

The hexadecimal digits you saw associated with "SSDP M-Search packet" isn't a media access control (MAC) address. MAC addresses are similar to 50-c5-8d-26-c2-06, i.e., Ethernet and Wi-Fi MAC addresses are usually displayed with dashes or colons between every two hexadecimal digits with a total of 12 digits, i.e., they are 48-bit addresses. What you are seeing is, instead, an IPv6 address - there are two versions of the Internet Protocol in use on the Internet today, the long used Internet Protocol version 4 (IPv4) and the more recent Internet Protocol version 6 (IPv6).

SSDP stands for Simple Service Discovery Protocol, which is a protocol used for Universal Plug and Play (UPnP). Some system on your local network, the one with IPv6 address fe80::50e7:d4f0:db:c4dc, is sending a packet to an IP multicast address, ff02::c. For IPv4, the multicast address is 239.255.255.250 while SSDP over IPv6 uses the address set ff0X::c for all scope ranges indicated by X ("X" in the packet you saw is "2").

I don't know why your system is contacting the Amazon Web Services (AWS) IP address nor the Google address.

C:\>nslookup 52.203.205.255 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    ec2-52-203-205-255.compute-1.amazonaws.com
Address:  52.203.205.255


C:\>nslookup 216.58.212.78 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    lhr35s05-in-f78.1e100.net
Address:  216.58.212.78 

I see the connection is to port 443, the well-known port for HTTPS traffic, but when I performed a 52.203.205.255 Reverse IP Lookup using DomainTools Reverse IP Lookup capability, it reported "We did not find any results for your lookup." Often, putting an IP address in that search tool will show you the fully qualified domain names (FQDNs) for websites hosted at the IP address (multiple websites can be hosted on the same IP address), but not in this case.

A 216.58.212.78 Reverse IP Lookup returned the same message. If you see a 1e100.net, that's a Google system. Google uses "1e100" in the name because that's a way of representing a "1" with one hundred zeroes after it, which is a googol.

Both of those packets may be unrelated to communications with the Battlefield server. The fact that they are retransmissions, which are sent when a system sent a packet, but didn't get an acknowledgement packet from the other side indicating it was received, though, may indicate that traffic to other sites is also experiencing packet loss at the same time as you are experiencing issues with the Battlefield server. You could filter on those two IP addresses to view other packets to/from them to get a better idea of why they may be appearing in the packet capture, if you were interested in why your system is communicating with those two IP addresses.

3
  • +1 Great answer. I have made a small analysis and added details to my question. Maybe you have an idea if there is more I can do from my side except giving the pcap file to my ISP. Maybe there is a way to make it worse so that we know what to look out for.
    – halirutan
    May 27, 2017 at 4:37
  • @halirutan, I added additional information to my response regarding the SSDP packet.
    – moonpoint
    May 28, 2017 at 3:14
  • Thank you for the update. The packets to google and amazon are most likely from a background updating daemon. Last night I turned everything off and kill every update service I could find. Indeed there were rarely other packets. It seems the network has a massive jitter problem. IMO the traffic should, in the best case, alternate between packets from and to the game server. This is often the case as can be seen here. However, on the critical lags it looks like this, where the packets from the server arrive too late.
    – halirutan
    May 28, 2017 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.