Packet Loss only on Mac

[rcafferky]

Hello,

My router is set up to route all of my clients over VPN. However it appears that my mac clients, specifically my iMac, randomly will drop packets while on the VPN. When I turn off the vpn on my router, there is no packet loss.

I tested other clients, and the first screenshot of terminal you see is a linux box that does not have any packet loss while on the VPN.

I had this issue on older versions of MaxOSC as well. Right now, i am on Big Sur version 11.2.1.

I have tested both Wifi and Ethernet interfaces and it appears to behave the same way.

I've tried playing around with the MTU settings. I have symmetrical fiber and MTU default is 1500. Nothing really changed when I set the MTU to smaller settings.

I also had this issue on my laptop (Macbook pro) over wifi and ethernet. It seems to be isolated to only macs..

Any ideas on what else the issue could be? Thank you.

-Ron

 

[chscag]

Welcome to our forums.

Have you tried changing to another DNS setting? I notice you're using 1.1.1.1 which is the same DNS that I use but no packet loss here. I'm not behind a VPN though.

 

[ferrarr]

The only difference is the "icmp_" before the sequence number. Do you know what that is?

 

[rcafferky]

Welcome to our forums.

Have you tried changing to another DNS setting? I notice you're using 1.1.1.1 which is the same DNS that I use but no packet loss here. I'm not behind a VPN though.

I have tried google DNS 8.8.8.8, but still having the same problem. Thanks for the suggestion though!

 

[rcafferky]

The only difference is the "icmp_" before the sequence number. Do you know what that is?

Thanks for the reply! I do know what ICMP is (Ping), but not understanding what the difference in the sequence number you mentioned. In the second screenshot, the ping times out completely. In my mind, this represents packet loss, but could be wrong.

 

[Raz0rEdge]

The sequence number indicating each ping packet that is sent out and a response shows up with the time and a lack of one indicates that's it's a missed packet, that's how the tool calculates the percentage packet loss.

So it's just an ever increasing number.

The DNS only comes into play if you were to ping a location by name, i.e., "ping google.com" means that a lookup has to happen to resolve google.com to some IP address and then the ping tool hits that IP address continually until you stop it. Changing the DNS just determine how quickly our resolve the name to the IP address, but has no impact on the actual ping functionality.

I'm on a VPN for my work as well and I can ping 1.1.1.1 with no packet loss. However, if I ping flood "sudo ping -f 1.1.1.1", I start seeing some packet loss like the following:

sudo ping -f 1.1.1.1
Password:
PING 1.1.1.1 (1.1.1.1): 56 data bytes
..Request timeout for icmp_seq 0
.Request timeout for icmp_seq 1
.Request timeout for icmp_seq 2
.Request timeout for icmp_seq 3
.Request timeout for icmp_seq 4
.Request timeout for icmp_seq 5
.Request timeout for icmp_seq 6
.Request timeout for icmp_seq 7
.Request timeout for icmp_seq 8
.Request timeout for icmp_seq 9
..Request timeout for icmp_seq 1324
..Request timeout for icmp_seq 1838
..Request timeout for icmp_seq 1851
..Request timeout for icmp_seq 2946
.Request timeout for icmp_seq 2947
.Request timeout for icmp_seq 2948
..Request timeout for icmp_seq 2958
..Request timeout for icmp_seq 4079
..Request timeout for icmp_seq 8727
.^C
--- 1.1.1.1 ping statistics ---
9782 packets transmitted, 9762 packets received, 0.2% packet loss
round-trip min/avg/max/stddev = 11.757/16.033/109.835/3.554 ms

Interestingly, note that the first few packets were missed and then nothing happened until 1324 and then 500'ish packets were good, but then 20 packets were fine after that, but then 1000 packets were fine after that and so on.

While interesting, this is only an issue if the packet loss is high enough. High packet loss means that you're constantly retrying your transmission and this has the impact of reducing your overall transmission performance and increasing time for anything to happen.

Most of the services these that streams usually buffer data, so intermittent packet loss is usually not a big deal unless it's high enough causing the buffer not to fill up correctly, this will lead to stuttering and jumpiness.

What sort of VPN are you using and is the same VPN (and server) on your Linux test machine?

 

[rcafferky]

The sequence number indicating each ping packet that is sent out and a response shows up with the time and a lack of one indicates that's it's a missed packet, that's how the tool calculates the percentage packet loss.

So it's just an ever increasing number.

The DNS only comes into play if you were to ping a location by name, i.e., "ping google.com" means that a lookup has to happen to resolve google.com to some IP address and then the ping tool hits that IP address continually until you stop it. Changing the DNS just determine how quickly our resolve the name to the IP address, but has no impact on the actual ping functionality.

I'm on a VPN for my work as well and I can ping 1.1.1.1 with no packet loss. However, if I ping flood "sudo ping -f 1.1.1.1", I start seeing some packet loss like the following:

sudo ping -f 1.1.1.1
Password:
PING 1.1.1.1 (1.1.1.1): 56 data bytes
..Request timeout for icmp_seq 0
.Request timeout for icmp_seq 1
.Request timeout for icmp_seq 2
.Request timeout for icmp_seq 3
.Request timeout for icmp_seq 4
.Request timeout for icmp_seq 5
.Request timeout for icmp_seq 6
.Request timeout for icmp_seq 7
.Request timeout for icmp_seq 8
.Request timeout for icmp_seq 9
..Request timeout for icmp_seq 1324
..Request timeout for icmp_seq 1838
..Request timeout for icmp_seq 1851
..Request timeout for icmp_seq 2946
.Request timeout for icmp_seq 2947
.Request timeout for icmp_seq 2948
..Request timeout for icmp_seq 2958
..Request timeout for icmp_seq 4079
..Request timeout for icmp_seq 8727
.^C
--- 1.1.1.1 ping statistics ---
9782 packets transmitted, 9762 packets received, 0.2% packet loss
round-trip min/avg/max/stddev = 11.757/16.033/109.835/3.554 ms

Interestingly, note that the first few packets were missed and then nothing happened until 1324 and then 500'ish packets were good, but then 20 packets were fine after that, but then 1000 packets were fine after that and so on.

While interesting, this is only an issue if the packet loss is high enough. High packet loss means that you're constantly retrying your transmission and this has the impact of reducing your overall transmission performance and increasing time for anything to happen.

Most of the services these that streams usually buffer data, so intermittent packet loss is usually not a big deal unless it's high enough causing the buffer not to fill up correctly, this will lead to stuttering and jumpiness.

What sort of VPN are you using and is the same VPN (and server) on your Linux test machine?

Thanks for the insight. I am using ExpressVPN in router configuration so all my devices are over the VPN. Yes, the Linux box is using the same VPN as all the other devices..

Maybe I shouldn't worry about it too much, the connection is somewhat reliable. But, annoying when I'm in and RDP session and sometimes in a video call I can see the packet loss in action. I does make me crazy because I'm on Fiber internet, and my linux box is not having this problem.. Just seems to be isolated to my Mac for some reason.

I do experience what you mention, with the buffer not getting filled up correctly. So, I know something is not quite right.

Any other configuration settings in Mac you think I can try?

 

[Raz0rEdge]

If the VPN is at the router level then all devices should be experiencing the same level of service. It's odd that the Macs are seeing this issue. Since you aren't configuring anything specifically on the Mac, there's nothing to tweak there. Plus, you said you tried wired and wireless, so that rules out interference from other wireless devices and so on.

I don't have anything concrete to suggest.

 

[rcafferky]

I found the problem.

It's not isolated to the mac, it is indeed the VPN provider.

It was really strange because on my Linux box, I did not see the packet loss.. But after physically watching it with my eyes I did see a delay in some of the ICMP pings.. Just no message saying "Request Timeout".

I went to www.packetlosstest.com and ran a few tests on various machines. It was consistent for all of the machines.. So I then tested different VPN servers with expressvpn on my router.. The Tampa and Miami servers had between 7-10% packet loss consistently. So I tried more servers around the US and Dallas TX had 0% packet loss. I still continue to test it and there is hardly any packet loss when I'm connected to Dallas.

Sorry for the fire drill here, and I jumped to conclusions that it was my mac.

So, if anyone is using a VPN.. I would definitely recommend www.packetlosstest.com and run a quick 10 second test to see how your VPN is performing.