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.
That's the one that killed my network every evening when I stopped working. My MacBook would go to sleep, with a Dell DA310 plugged in, and serving as its network connection.
I would go on a walk and every time the missus would call me to tell that the network is down again...
My experience: 95% of all network problems are dodgy cables. The other 5% is dodgy switches.
The switches one is a bear to debug. I just tossed out two old switches, because I wasn't sure which one was the one that polluted the network. I could have spent several hours, setting up little sandboxes, but it was easier just to toss them both, and get new ones.
I just retired some 3com 1900 series 1gbps switches for my home lab. Only problems I've had with them were those dell docks I mentioned corrupting arp tables requiring a full network reboot to resolve but it also could be reproduced on Cisco and Dell switches so there's that. HP still fully warranties the damn things to this day.
I used to have a dell vostro notebook that every time I logged into the network with windows, it would drop every other device on the wifi.
Funny thing, is that if I used linux, the router would be alright and not collapse.
Never found out the reason. In the end I divorced the wife and she got that notebook.
I find it curious that the wifi interface and the USB/ethernet interface are using the same MAC address. Nothing keeps a computer from being attached with both at the same time, in which case this would definitely break things.
I believe Macintoshes "remember" the most recent IP they were given on a network rather than always doing a DHCP.
It's one of the reasons given for why people say Macs "feel better" e.g. you sit down in a room with a friend who has a Dell. Your Mac gets WiFi almost immediately while they have to wait a few seconds even though both of you have been on this network before.
One of the benefits of owning the stack all the way from bare metal to OS to applications.
We had Dell laptops with the dock. If you undocked the laptop under the right circumstances, which we could never determine, the dock would go into a mode where it would start spamming IEEE 802.3x PAUSE frames into the network as fast as it possibly could.
Our switches didn't handle this correctly and would forward the PAUSE frame as it if it were a broadcast. When this happened, the entire network would cease to function until the offending dock was found and disconnected.
Sounds to me like something's crashing on disconnect, the ethernet watchdog notices a full receive buffer so it starts sending out pause frames, but the buffer never gets emptied anymore so the watchdog keeps sending out pause frames. Similar to like how you keep hearing the same audio sample over and over again when Windows bluescreens.
I never root-caused it so thoroughly, but I have an Anker USB-C hub that causes exactly the same effect when it's unplugged from a machine while still connected to ethernet. Took me months to figure out wtf was happening.
Why would a MAC address duplication "lock up" your whole network? I would guess that at worst that particular laptop would either intermittently get packets or not get packets at all. Which is bad, but not a "lock up". Other stuff should still work.
I agree with your assessment. A duplicate MAC address could cause a problem for one device, but it shouldn't have caused a full network outage.
Simply opening WireShark for a few minutes might have helped the poster identify their problem faster. Maybe you would observe the same frame transmitting again and again, maybe you would see corrupted frames, or maybe nothing at all.
Ethernet switches keep track of which ports have which MAC addresses behind them. This is stored in the CAM table of a layer 2 switch. When duplicate entries occur, this result in MAC address flapping and switches have different ways of handling this, which may result in network instability.
Things like that can cause routing "loops" in your network which can mess up everything, not just the device in question. We've had that issue with "dumb" switches.
First time I run a dhcp server by accident and suddenly went sideways but the blast radius was small,
Second time and more interesting one,
My campus had a mac address allow list; when I got a new computer and didn't want to handle the process of updating my access access permission, I just run a script to change my mac to the old known address.
Later, I also sold the old computer to another colleague which didn't bother to register as well since everything was working. Long story short, we keep disconnecting each other.
One day I was, "c'mon, I'll fix this". Opened wireshark and started to capture network traffic. I've got a list of mac addresses from the pcap dump and every time I got disconnected, I ran the script spoofing my address to the next one in my list.
That worked fine until the day I spoofed the mac address of a central managed switch that shit itself out of the network.
I recently solved a 5-10 year bug in a similar vein. My local network DHCP shared an IP space with the VPN to which I have been connecting. This was causing intermittent and "unexplainable" connection issues that were ultimately due to plain old IP-address collisions.
Sadly, the immense joy that I felt upon resolution is mysteriously lacking from this person's post.
Readit News
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.
I would go on a walk and every time the missus would call me to tell that the network is down again...
The switches one is a bear to debug. I just tossed out two old switches, because I wasn't sure which one was the one that polluted the network. I could have spent several hours, setting up little sandboxes, but it was easier just to toss them both, and get new ones.
Never found out the reason. In the end I divorced the wife and she got that notebook.
Wifi is weird.
It's one of the reasons given for why people say Macs "feel better" e.g. you sit down in a room with a friend who has a Dell. Your Mac gets WiFi almost immediately while they have to wait a few seconds even though both of you have been on this network before.
One of the benefits of owning the stack all the way from bare metal to OS to applications.
Our switches didn't handle this correctly and would forward the PAUSE frame as it if it were a broadcast. When this happened, the entire network would cease to function until the offending dock was found and disconnected.
Simply opening WireShark for a few minutes might have helped the poster identify their problem faster. Maybe you would observe the same frame transmitting again and again, maybe you would see corrupted frames, or maybe nothing at all.
First time I run a dhcp server by accident and suddenly went sideways but the blast radius was small,
Second time and more interesting one, My campus had a mac address allow list; when I got a new computer and didn't want to handle the process of updating my access access permission, I just run a script to change my mac to the old known address.
Later, I also sold the old computer to another colleague which didn't bother to register as well since everything was working. Long story short, we keep disconnecting each other.
One day I was, "c'mon, I'll fix this". Opened wireshark and started to capture network traffic. I've got a list of mac addresses from the pcap dump and every time I got disconnected, I ran the script spoofing my address to the next one in my list.
That worked fine until the day I spoofed the mac address of a central managed switch that shit itself out of the network.
:)
Sadly, the immense joy that I felt upon resolution is mysteriously lacking from this person's post.
Edit: DHCP not DNS