nmap -sn 192.168.0.1-255
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.
https://serverfault.com/questions/462178/duplicate-mac-addre...
what happens depends on your LAN setup, but generally its a fail.
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.
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.
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.
In summary: it's fine.
I know Windows gets upset when that happens but the network seems to still work.
sync boot
I always wondered if there was a way to further exploit that.
I just switched to my cell phone data if the wifi was too slow.
In-room, you get free internet access, but in the windowless ballroom with spotty cell-service, there's nothing available for free.
"Follow the money"
For extra fun, consider how phone bills attempt to "pass through" their own tax obligations, which have little to do with your own incremental usage, in the form of 'recovery fees' tacked onto bills. I suspect we'll eventually see those creep into all kinds of transactions, especially among other monopolistic/oligopoly businesses where you have little if any choice.
That's basic price elasticity of demand and entirely unsurprising. When something costs 10% more, people buy less of it in general.
We also buy more things priced at $99.99 than at $100.00, which is more of the psychological trick than it is rational price elasticity.
Hard to advertise to a wide audience when the final price after tax is one of 12 different prices depending on where they live.
I don't know of any US businesses other than waffle house that always include all taxes in the listed price, however.
Regardless, I'm not sure why people consider it such a big deal. It's consistent across the board and it's relatively basic math to estimate what the total would be.
I've lived in places that do it both ways and it's a non-issue.
I think the norm is to show whatever price you want, with some countries banning that for fairly obvious reasons.
There's still some stragglers though, offering "basic" access free but charging for higher data limits, faster bandwidth, more devices. You can often get the higher plan just by signing up for the hotel's loyalty program.
From my point of view, free WiFi became normal when it became less important because of affordable mobile internet.
From the point of view of the hotels it was about recovering their missing income after customers got mobile phones and stopped paying half a dollar per minute for using the hotel phones. There was a period when both mobile roaming and hotel WiFi was expensive, so I often went out from my hotel room and bough a local SIM-card to get internet access.
What annoys me most, is that only when I finally could get a laptop that would work a full transatlantic flight on one charge, then suddenly airplanes all got power outlets.
I would have loved to take advantage of this since my wireless earbuds were significantly better than the wired pair I had. Unfortunately, a little pop-up warned me that this was not available on Android 13 devices. I was more than a little annoyed, but also curious as to why this might have been the case.
Messaging and Notifications basically follow the same protocol. Even though I usually have notifications disabled, I go and activate it for anything I care about - News, Weather, Slack, Whatsapp (yes I have that silenced). Every single message pops up as a notification. Could be bank alert, Ring alert, homekit alert, whatever ... it just shows. So you can keep tab on things you care about, and if you are really needed, well you can pay and get on the full Wifi. And anyways you can iMessage to communicate if needed.
It's interesting what does and doesn't go through. e.g. Facebook notifications update, but not the content. I guess that's because they use the same channel as FB Messenger.
Granted, being a NOC engineer at Wayport (now AT&T WiFi) certainly helped me understand how it all works.
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.
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.
at least they bothered to type something!
> 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
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.
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 makes me really reconsider my past struggles with this form of Internet access.
A multicast packet might vary based on physical distance to the imposter?
Because if that's a crime we're screwed because then it's illegal to read, or listen.
https://www.theverge.com/2021/12/31/22861188/missouri-govern...
https://github.com/aselvan/scripts/blob/master/macos/free_wi...
The state of "open Wi-Fi" security is actually really sad. I'm not aware of an easy way for the airline to actually do better than this!
I suppose they could use Opportunistic Wireless Encryption [1] and bind session authentication to that (i.e. authenticate a given OWE session, not a given MAC address) if the device supports it, as at least modern Apple devices do? But I have no idea how stable an OWE session is; it would be very inconvenient to have to login again every time my device switches between access points.
In any case, I'm sad that this isn't a solved problem yet, and paid Wi-Fi (as well as securing free Wi-Fi) still requires custom and clunky solutions like unreliable captive portals that need to pass through selective traffic (e.g. for 3DS, for payments, sometimes emails for password reset codes etc and more).
A standardized endpoint and API would also be nice, i.e. something to tell the client whether it's connected, restricted (i.e. able to only access a limited set of hosts such as the in-flight map as described in the article), or needs to pay/authenticate (and if so, at which URL). This could then yield an authentication token, to be provided for seamless reconnections for the same session.
There's "Hotspot 2.0" and WPA-EAP (i.e. WPA Enterprise), but these don't really have a good story for "pay via web portal" style usages and are more geared towards wireless carrier operated hotspot networks and corporate scenarios, respectively.
[1] https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encrypt...
In case of in-flight Wi-Fi, the credentials/QR code can be printed on the boarding pass, or available in the app (the app caches it in advance while it's still on the ground, so when in the air you can use those credentials to connect).
This doesn't cover 100% of use-cases but it would at least cover a big one (a significant amount of public Wi-Fi is "value add" to another service - whether restaurants, hotels, flights, etc where there's an existing channel to provide one-off wi-Fi credentials over), it's a shame nobody deploys this.
One concern might be expiring access credentials (not sure if most OSes will re-prompt for a new password or just give up), but you could just make the EAP credentials per-user instead and redirect users to the captive portal again once needed.
This leaves clients not supporting WPA-EAP, but these could just continue using the regular unencrypted/MAC-authenticated service.
Only works with IFE equipped planes, of course.
Though you could route around these problems, but giving them both a scannable code, and underneath some credentials as plain text they could type.
That way you'd at least have the protection of the WPA GTK.
It's not airtight, but better than the system it would be replacing.
PS: I'm a couch expert so I have no idea if there's a problem with this idea.
The user can go in and forget the open network of course, but most won't know to do that.
This hack just goes a step further to plot the data over time.
I used to travel a lot for work and just refused to pay for WiFi. This was good in airports and coffeeshops when you still had to pay to connect.
Now it's hardly needed, but I could see how it would be helpful where there's still a cost to connect.
Well, if he doesn't know there's anything wrong with it, it's not really temerity.
There was another little hack that I used as a little kid. Remember when airlines would sell or rent special headphones to watch inflight movies? The port was just two holes beside each other and the plug was two tubes. Before a flight, I would stop by one of the fast food places in the terminal and grab a handful of straws (preferably ones with a bendy joint). When I was on the plane I would connect the straws by fitting them into each other to create a long straw. Put one end into the port on and the other into your ear and you got free movies with audio!
20 years ago, all I saw were dual mono bayonet jacks you'd need an adapter for to plug in normal headphones, but straws would get you nowhere.
I was curious so I searched: https://simpleflying.com/inflight-entertainment-headphones-e... - pneumatic headphones from the 1960s were used on Delta as late as 2003, but electronic headsets debuted on 767 in 1982.
Apparently the dual mono jacks are to discourage people taking the headphones, rather than restricting access to audio.
This is in contrast to other instances of public Wifi.
Great time to have an Android device with hotspot handy. :)
Most laptops can't do this, right?
Maybe at the cost of latency because it has to switch channels back and forth?
> Most laptops can't do this, right?
Any laptop can do this if you plug a USB WiFi dongle into it :P
Not necessarily. It can be a client on 2.4Ghz and an access point on 5Ghz. Even without that, if it has MIMO, then one of the antennas can be receiving 2.4Ghz while the other is sending (at least in theory, if the crosstalk between the antennas is low and the selectivity of the receiver is sufficient).
[0] https://learn.microsoft.com/en-us/windows/win32/nativewifi/a...
I used to spend a lot of time at JFK back when they still charged for WiFi. I watched a lot of Netflix for free by just tunneling to my home network and connecting to my VPN server.
Either that, or they just felt like throwing a fellow nerd a bone. If you ask the PM, "should I block SSH" they'll say yes, but if you just put it in there, who knows ;)
If I'm ever in charge of rigging up a captive portal system like this, I'm certainly going to do something similar if I can get away with it. Maybe even put a hint on how to bypass in the portal's page source. "ssh works on port 46969, don't tell anyone." > rot13 > base64 -> "cache-burst-ID: ZmZ1IGpiZXhmIGJhIGNiZWcgNDY5NjksIHFiYSdnIGdyeXkgbmFsYmFyLgo="
May be too obscure though.
You told him off for such a small thing? You were impressed but didn’t give encouragement? You are a horrible parent.
It’s slow, but it works and is a handy “last resort” tool.
I had to tell him not to do that, but I was kind of proud of him for having the temerity to go for it.