[cehrlich]

According to many commenters in the linked thread, it's fixed in MacOS 13.2.1. Not great that it happened at all, but good to see that it was a software issue.

[segfaultbuserr]

Is it a software issue, or a hardware issue that could be worked around in software... (sorry for the rant as an embedded system developer).

[loeg]

The latter is very common in the desktop/server space, too. If you ever write or work on drivers, you know.

[segfaultbuserr]

> If you ever write or work on drivers, you know.

Especially when the hardware vendor doesn't provide public documentation on the correct workaround.

[throwaway5959]

To the end user, if it doesn't impair performance, does it matter?

[Dylan16807]

To the end user, and doesn't impair performance, and covers all edge cases, then it doesn't matter if something is a workaround.

But we're not being end users here, we're trying to look at what went wrong. And we don't know if the other two are true either.

[mbreese]

And, if it's something that's worked around in software (meaning, it was a hardware issue), that might have issues for things like Asahi Linux, which probably won't have that workaround in place.

[makeitdouble]

Arguably it would impact the support for other OSes, especially alternative ones who'd need to reverse engineer the workaround and/or write their own to get the network stack working.

It could also fall apart the day Apple decides this machine is not supported anymore, and their next OS won't have the correct drivers anymore. It's their prerogative, but will sure suck for the machine owners.

[ed25519FUUU]

I have MacOS 13.2.1 and it's definitely not completely fixed -- but better.

I did a ping test against my home router and I still get about 10% packet loss. Much better than the 40% when I first plugged it in.

[singularity2001]

Uff yeah it's still horrible!

PING fritz.box (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=11.845 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=24.287 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.120 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.630 ms Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.801 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.139 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.772 ms Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.784 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.674 ms

The above suggestion fixes it, hopefully permanently: settings->network-><ethernet interface>->details->hardware "change anything, safe and undo"

[icedchai]

Can you try a speed test? That level of packet loss will make TCP connections perform incredibly poorly.

[ProAm]

10% loss inside your home network is bonkers bad.

[icedchai]

Absolutely. I had ~2% loss on an old cable modem and it would drop my upload speeds to single digit megabits.