Its wifi. You both just pick up the same frame when it is broadcast, then it sees two stations (a level below IP) with the same MAC. Most routers just don't care about that. (it's technically a valid edge case that two stations have the same mac address. It should be vanishingly rare in the wild ... but this is a practical example of why it isn't).

If there's multiple hotspots behind the same controller, you may well get switch port fighting.

If STP[1] is enabled, but that is unlikely since you'd have dropped connections when roaming for the reasons you just gave. Most likely, STP is not enabled on these networks.

[1]: https://en.wikipedia.org/wiki/Spanning_Tree_Protocol

A switched port learns the Mac address for packets sent into it. If port 1 sends a packet with Mac a, the switch associates that address (a) to port 1. When another node sends a packet onto another port with the same mac, say on port 2, the switch will move the learned address a to port 2 and remove it from port 1.

When a switch has learned a mac address all traffic destined to that traffic would be immediately switched to that port. If the switch has no record for that specific mac address it floods all ports except the ingress port. This is expensive and means other devices receive traffic that isn't intended for them so they waste time dropping it.

So in networks that have no protections against those attacks then this could very well be a problem if there are multiple access points and the two nodes are on different access points.

Except that this is a normal thing on wireless networks. A station may roam many times within a few minutes, and due to reflections, may even be in more than one place at a time.

I believe a UE is only ever attached to a single BSSID for a given SSID at a time.

Let me tell you about 2km, directional links and reflections one day, over a beer.

STP detects loops between switches, not MAC addresses moving between them (or between APs).

"vanishingly rare"

I once bought a cheap Bluetooth dongle from China. Its MAC address was 11:11:11:11:11:11 Obviously there are now a lot of bluetooth dongles in the wild with the same MAC address.

I still see a lot of "(to be filled by OEM)" on computer parts

at least they bothered to type something!

Yes so that is the hub case (2nd half of my comment) -- clients will RST each others' connections then. Unless you are MAC cloning but not IP cloning.

A computer doesn’t send a RST when it gets an unknown packet…

Yes, it does, that is the purpose of RST [1]:

> As a general rule, reset (RST) is sent whenever a segment arrives that apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case. There are three groups of states:

> 1. If the connection does not exist (CLOSED), then a reset is sent in response to any incoming segment except another reset. A SYN segment that does not match an existing connection is rejected by this means.

It's possible for a node to be configured not to do this, but this is the default behavior.

[1] https://www.ietf.org/rfc/rfc9293.html#name-reset-generation

So if two wifi clients have the same MAC and IP, everything works fine for both of them?

"everything works fine" might be overstating a bit, but what happens to packets you weren't expecting when you don't have a connection open for them to go into? They probably get ignored by the network stack.

Worst case scenario, the router/service endpoint sees your connection responses and the other party's strange NACK responses, but I honestly don't know enough about how it works to say "everything works fine"

I'd guess that connectionless protocols will work fine and connected protocols will also work fine. The truth is probably YMMV by protocol, but there is truly no way for the wifi router to detect this is happening or isolate the redundant stations - it's an unencrypted broadcast. The only way this goes sideways is if a connection protocol is engineered to make it go sideways when you try to do that.

I'm pretty sure that any such protocol which succumbs to any unencrypted (or incorrectly keyed) traffic that isn't from the designated counterparty is insecure to begin with. It should be resilient against DoS, so most protocols aren't going to have that vulnerability. Again, I'm guessing, but I'd hope.

I imagine this can only possibly work with unencrypted WiFi.

Still boggles my mind that WiFi clients don't establish an encryption key with the AP and encrypted their traffic even without a shared secret. Yes, that means you can't authenticate the AP, but it would still protect against passive snooping.

That’s what OWE is supposed to fix https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...

Usually doesn't matter... The other person will get frustrated and disconnect and reconnect a few times, and finally give up and read a book...

> The other person will get frustrated and disconnect and reconnect a few times, and finally give up and read a book...

That makes me really reconsider my past struggles with this form of Internet access.

Yeah...

Time to consider instead: walk through the plane, look angrily at the other passengers, one at a time, asking: "Do you use 192.168.x.y?". That can solve the problem

Or convince the flight attendants to including “MAC address spoofing” in the spiel about destroying or tampering with lavatory smoke detectors.

Presumably there is a way to find out which other wireless client is impersonating another in a confined environment like an airplane.

A multicast packet might vary based on physical distance to the imposter?