|
|
|
|
|
|
by Nextgrid
812 days ago
|
|
|
That post has provided no proof this is indeed a MAC address conflict issue, and as other comments suggest even an actual MAC address duplicate should only cause connectivity issues for said MAC address and no other devices. MAC addresses belong to the NIC and not the machine, and while the OS can override them, it won't do so without express user intervention. I'm especially skeptical of the Ethernet MAC being a duplicate of the Wi-Fi MAC, as this would cause obvious issues (especially considering both Wi-Fi stays up even in the presence of Ethernet, it's just that the routing table is configured to prefer the Ethernet over it) - if this was indeed the case, he would never have had network access on that machine. However, it is known that some Realtek USB Ethernet controllers have unexpected behavior when powered but no longer enumerated on the USB bus, and they send some low-level Ethernet frame that effectively causes all traffic to stop on that L2 network segment. I'm not sure who is at fault (whether the controller or the switch it's connected to mistakenly rebroadcasting that frame), but here are more details: http://jeffq.com/blog/the-ethernet-pause-frame/ and https://lucumr.pocoo.org/2020/7/6/usb-c-network-hubs/. |
|
|
It's the people who thought Ethernet Pause was ever a good idea.
I've only seen it lead to tears. In all of the situations I've run into, it would be better to drop packets that are arriving too fast to handle than to try to fix it up by trying to do flow control. Ethernet is unreliable, and packet loss is the overload signal; PAUSE changes overload from drop to buffer, and then you end up with problems with overlarge buffers. In addition to things like where a multi-queue nic has one queue overloaded and sends PAUSE, which results in starvation for the other queues; or PAUSE getting broadcast over a switch when it shouldn't have been, etc.