Network devices forward (switch, more technically) packets to and end device based on an internal MAC table (send packets for DE:AD:BE:EF to interface ge-0/0/0.0) and most devices populate their MAC table simply by looking at input packets and sending the "next" packet for that MAC address out the "last" received interface.
If two devices in a network have the same MAC address, they will effectively "fight" for control of the packet flow. You can win that fight by sending a lot of packets.
In practice, the other person is going to get annoyed and give up.
There are lots of technology which avoid this issue now, but the two primary ones are 802.1x (used in corporate/government environments) and DHCP snooping which can be much more broadly deployed. 802.1x is very complicated and I won't go into it, but, DHCP snooping works by limiting L2 forwarding (MAC table population) to only what the DHCP server says the end device should have and it does this just by inspecting the DHCP replies (no custom protocol) with some vendor specific extensions on the DHCP server side for complex scenarios (you can even do things like put ports in a specific VLAN based on the DHCP reply).
This works fine on a physical layer and most hotels are probably using something similar now (less for malicious abusive reasons, though that's a thing) but also just to work around poorly behaving devices and to reduce customer complaints. If you care (and have a modest amount of money) MAC and IP spoofing are dead on the physical layer.
For the wifi layer, very similar stuff exists in high-end gear (Rukus/Cisco) and is starting to trickle down to prosumer level gear like unifi. If you care (and have serious cash for Rukus) MAC and IP spoofing are also dead on the wifi layer.
Fun anecdote from the early 2000's re: duplicate MACs:
Embedded IP time clock kept intermittently barfing out frames with the source MAC addresses of other devices on the network. The switch would update its MAC table and direct packets to this device. The Customer's AS/400 would kill all remote terminal sessions when the clock ended up w/ the AS/400's MAC. (They were doing a layer 2-based connection to the AS/400-- APPN, I believe it was called... Ugh, it was temperamental and didn't like any layer 2 "hiccups".)
MAC addresses flapping between ports is one of those "breaking the laws of physics" kind of problems that teaches you to question your assumptions. Gear with a crazy brain can do anything it wants to and it doesn't care about your assumptions.
> it was temperamental and didn't like any layer 2 "hiccups"
The clock was probably doing the "correct" thing when it got a TCP packet for a connection which it didn't recognize and sent back an RST, which caused the client to abort.
> kind of problems that teaches you to question your assumptions
Yep. I learned a lot from dealing with large layer-2 networks (commonly running on hardware not suited for the task). Mostly I learned to never run large L2 networks.
That greatly depends on whether the medium is broadcast (like a radio) or broadcast-like (a shared copper wire) and if it has CSMA/CD logic. Many of the replies are losing that detail and thinking of how it would effect a 1000base-T network, which maps MAC addresses to specific ports.
For a broadcast network, the answer could be 'nothing' in the sense that both receivers would get the same traffic. The IP stack would then throw away packets destined for the other computer unless they were UDP broadcast or multicast, and even then it would only notice if someone was running Wireshark.
Advanced wifi devices/meshes will use beam forming and mesh allocation and might degrade if there were MAC duplicates, but I think they will generally operate in a non-exclusive basis due to end point movement and fading, so both computers will get a good data rate.
Great question. It could, but there is a strong chance that the true recipient has already partially or fully ACKd the segment, thereby changing the sequence number and preventing a reset.
No way to tell for sure, but I can only assume that he had actually hijacked somebody else's connection and the other person's device stopped working for them. I sure wasn't going to stand up and ask the plane if anybody had had their internet plan hacked...
It more or less turns into an ARP cache race, only one device is gonna win. You can do some tricks with gratuitous ARPs as well for "dumber" networks, but more sophisticated setups usually have some broadcast ARP filters that are tied to an auth layer (radius, 802.1x. etc) and will drop broadcast frames from un-authed hosts.
I should probably know this too, but I'll speculate wildly instead.
MAC is Layer 2, IP address is Layer 3. One way or another, the packet destined for the person you're spoofing will end up at your computer and work its way through the layers. From there, if it's a TCP/IP packet, I think it'll get filtered out at Layer 4 (transport) because your computer wasn't one of the parties that initiated the TCP connection (the sequence numbers won't line up, etc).
Packets being broadcast to multiple machines is common enough in various network setups, it's up to the individual machine to decide whether to process or drop the packet.
Since Wi-Fi is a broadcast medium, shouldn't it not matter? With a switch it would break things because MAC tables, but a Wi-Fi AP is a hub. Each device will receive packets for both devices, sure, but will that break things?
I know Windows gets upset when that happens but the network seems to still work.
