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.<p>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 <i>never</i> have had network access on that machine.<p>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 <i>who</i> is at fault (whether the controller or the switch it's connected to mistakenly rebroadcasting that frame), but here are more details: <a href="http://jeffq.com/blog/the-ethernet-pause-frame/" rel="nofollow">http://jeffq.com/blog/the-ethernet-pause-frame/</a> and <a href="https://lucumr.pocoo.org/2020/7/6/usb-c-network-hubs/" rel="nofollow">https://lucumr.pocoo.org/2020/7/6/usb-c-network-hubs/</a>.