Incoming packets are intermittently dropped by macOS

Aaargh79 wrote:

it already happens pinging the IP of the switch the machine is directly connected to. Pinging the Mac from the switch's diagnostics tools shows no packet loss in that direction.

The next step ...

Do you really need a next step?

Try a different client. Then try a different switch.

Aaargh79 wrote:

If you had read the whole thing, you’d see that the problem is not the switch. The responses actually *do* arrive without delay. This is a software problem, not a network hardware problem.

I read the whole thing. It sounds like a case of premature diagnostics. You have to first isolate the problem. You have at least 5 different devices with up to 5 different operating systems. The most likely candidate is the switch. Since the switch is a core component that is difficult to swap out, you should try changing the client first.

I found this thread searching for a similar issue with my Mac Studio 10G Ethernet (Speed: 5000Base-T, Duplex: full-duplex, MTU: Standard (1,500), AVB/EAV mode: Disabled).

When my Mac returns from sleep sometimes the Ethernet connection under System Preferences shows up as being connected while all TCP/IP traffic seems to have stopped. I can't access my switch or router via any browser with their IP. Practically it looks like the ethernet connection is down.

But I can still send pings. When I ping my switch and router both of them show sporadic ping timeouts.

Can you tell me what tcpdump commands you used to determine that there's no actual packet loss? Maybe we can compare notes this way.

I already filed several tickets in the Apple Feedback Assistant.

When I deactivate and reactivate the Ethernet connection via System Preferences everything is back to normal for a while.

Funny thing is, I have a second Mac Studio same configuration with 10G Ethernet connected to the same switch which never shows this behaviour. I already switched ports between both of them. It didn't change anything. The issue is isolated to my Mac Studio.

For reference here's the output I see when I ping my switch and router when the issue occurs. They both have a similar ping pattern.

64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=1.102 ms
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
64 bytes from 192.168.10.1: icmp_seq=6 ttl=64 time=0.943 ms
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
64 bytes from 192.168.10.1: icmp_seq=9 ttl=64 time=1.023 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
64 bytes from 192.168.10.1: icmp_seq=17 ttl=64 time=0.993 ms
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
64 bytes from 192.168.10.1: icmp_seq=20 ttl=64 time=0.801 ms
64 bytes from 192.168.10.1: icmp_seq=21 ttl=64 time=0.990 ms
Request timeout for icmp_seq 22
64 bytes from 192.168.10.1: icmp_seq=23 ttl=64 time=0.894 ms
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
64 bytes from 192.168.10.1: icmp_seq=26 ttl=64 time=0.869 ms
64 bytes from 192.168.10.1: icmp_seq=27 ttl=64 time=0.863 ms
Request timeout for icmp_seq 28
Request timeout for icmp_seq 29
Request timeout for icmp_seq 30
64 bytes from 192.168.10.1: icmp_seq=31 ttl=64 time=1.383 ms
64 bytes from 192.168.10.1: icmp_seq=32 ttl=64 time=0.890 ms
64 bytes from 192.168.10.1: icmp_seq=33 ttl=64 time=1.512 ms
64 bytes from 192.168.10.1: icmp_seq=34 ttl=64 time=0.990 ms

I didn't say the switch was the problem. I said it was most likely the problem since all devices are connected to it and you see no problem between the switch and the mini.

If those responses were "perfectly valid", then you wouldn't have been posting this question in the first place. Something in your network isn't happy. By default, everything should work perfectly. Macs are relatively difficult to configure in the first place. So by extrapolation, they are relatively difficult to configure incorrectly. The exact opposite is true for the switch. Furthermore, the switch is relatively easy to swap out, change ports, change cables, bypass entirely, etc.

But if Wireshark says there is no problem, then that proves that you have no problem, right?

Aaargh79 wrote:

The mac is actually a relatively complicated setup. It runs a VPN client and several VM's.

Call me crazy, but maybe you ought to have led with that. 😄

I don't know what to tell you. If you are running a consumer VPN, then nobody's going to give you the time of day. It was never designed for that. If you are running an enterprise VPN, then, in theory, you have some support. I would be shocked if your enterprise VPN support technicians knew anything about the Mac or cared in the slightest. Most likely, they will just blame Apple and be done with it.

And then there's the VMs. Are you talking about problems connecting to one of the VMs? Multiple VMs? The host? What VM product are you using? How is the networking on those VMs configured? A year ago, you might have had a bit more interest from your VM vendor support. But recent developments have wrecked the Mac VM market. You're on your own there, too.

You realize this is a user-to-user tech support forum for consumer Apple products? It sounds like you are hoping for some known problem with macOS dropping packets? Sorry. News to me.

Ok. Maybe back up a bit.

What do I know? You have a Mac mini used as an Xcode build and VM host. That pretty much eliminates the PPC models, so this machine dates from no earlier than 2006, most likely at least 2009, to 2023. I would have assumed it to be an Intel machine, but when Apple Silicon was first introduced, it seemed like people were only using them for VMs. Your post sig says M1 2020, but those signatures aren’t reliable.

This mini is connected via Ethernet to a switch. It is connected to some (remote?) git, Jenkins, and possibly file servers of some kind. At least some of these connections are using a VPN that you assure us is not consumer-grade and irrelevant to any networking problems.

This mini is experiencing random loss of networking episodes of unknown duration. This problem began at some point between 2006 and May 9th, 2023.

You can detect no problems when running diagnostics from the switch. When running diagnostics from some other computer of unknown vendor and configuration, possibly on some other network, you are detecting random loss of some large packets, but only from the OS perspective. Your diagnostic tools Wireshark and tcpdump report no problems.

What don’t I know? Specific model of mini. Configuration and performance characteristics. Is it crashing or running out of RAM during these episodes? The time that these problems started happening. Any configuration changes to the mini that occurred immediately before the problem. The current OS version of this computer. The specific VPN vendor and architecture. The specific VM vendor and guest systems. Whether these diagnostics and packet losses were detected on the mini itself or some other computer. The vendor, configuration, OS version of said diagnostic client. The network connection between this computer and the mini. You’ve said it isn’t over the VPN. But is it also directly connected to the same switch? Are these half-loss of packets being detected actually the casus belli of the network disconnects experienced on the mini?

I’m sorry, but I just don’t have enough information to make any kind of guess. I have heard of problems with people trying to do split tunnels on certain commercial VPNs where they will lose all connectivity. That doesn’t sound like the same problem, but it could be related. Modern Mac networking is not straightforward. People assume it is like Linux or BSD, and it isn’t. You have more information, tools, and access than anyone here. You sound more competent than most IT folks. I’m not confident that your diagnostic tools are all that reliable. Wireshark seemed ignorant of modern Mac configurations for several years. I don’t know if that has ever changed.