Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

what will happen if i clone another pc on a wlan network? consider the following scenario.

  • PC1(victim) mac1 ip1
  • PC2(attacker) mac2 ip2.

I set mac2 = mac1 and ip2 = ip1

i ran the following script on PC2

#!/bin/bash
ifconfig wlan0 down
macchanger -m ac:81:12:a2:4e:3a wlan0
ifconfig wlan0 192.168.1.5
route add default gw 192.168.1.1 wlan0
ifconfig wlan0 up

i managed to clone pc1 and access the internet via pc2 but pc1 lost his connection to the internet. pc2 works fine as if he kicked pc1 out of the network. i really can't find a logical explanation for this problem. why pc1 lost his connection?? a router should not be able to differentiate between them and pc1 should maintain his connection to the internet

share|improve this question
1  
Advise running wireshark to see what's going on on the network. Pretty educational, and as @MDMarra said, pay attention to ARP packets... –  Deer Hunter Feb 16 '13 at 17:21
    
i spent the whole day on wireshark nothing special :( –  george Feb 16 '13 at 17:32
    
what is the model of AP you're testing this with –  MDMarra Feb 16 '13 at 18:43
    
d-link wireless dsl AP model no: DSL-2640U original firmware never updated –  george Feb 16 '13 at 18:54
add comment

2 Answers 2

The behavior is both expected and normal, because of ARP.

share|improve this answer
    
what do you mean by "expected and normal"? why pc1 lost his connection? there is no reason for that. i am cloning both ip and mac so ARP has nothing to do with it. pc1 does not mention an ip conflict. both are represented as a single pc –  george Feb 16 '13 at 17:13
1  
@george The switch keeps track of which MAC is on which port, so when you put the same MAC on a second port it loses track of that MAC on the first port. MAC addresses are supposed to be unique, so cloning a MAC breaks things. –  freiheit Feb 16 '13 at 17:27
    
@freiheit it's a wireless network!!! i know how switches work. i have a ccna :D –  george Feb 16 '13 at 17:30
add comment

A 802.11 network, unlike a wired network, use acknowledgments to indicate that a frame was received successfully. It is used because the link is so lossy that most upper layers would be unable to cope with the sheer loss rate, so a lack of an acknowledgment will result in a retransmission. And it solves another problem: a 802.11 network is a shared media network, so if two stations send at exactly the same time, a collision occurs, and the frame is lost for both.

If two WLAN stations use the same MAC address in an open network, then the network can be rapidly brought down for both stations, because reception of data would likely fail:

  • If both station successfully receives a frame from the AP, both will acknowledge at the same time. And when i mean "same time", it is 10µs after the frame reception has ended. So it is guaranteed that both acknowledgment will collide with each other, and the AP will not receive it, so will retransmit.

  • If one station receives a frame successfully, but not the other, then the first station will acknowledge, and the other station will never receive the frame.

As such, when your network is completely borked down, disconnection or huge performance loss will occur, and the first to disconnect loses.

If your network is protected by WPA/RSN-PSK (without SAE), and both station knows the PSK, there is another problem: the PSK is not the encryption key by itself, but is used to derive an randomly generated temporary encryption key during a Four Way Handshake.

While a station is connected, if another station initiates a connection normally, then the AP will most likely forget the old encryption key and will use the one negotiated by the new 4 Way handshake. Depending on the implementation of the previous station, it may disconnect silently, or will participate with the new 4 way handshake. If both station participates with the same handshake, due to the way the 4 way handshake is typically implemented, the first station to respond wins, and the other station will disconnect, because it will fail to authenticate the AP.

And if the attacker retrieve the temporal encryption key (e.g. by eavesdropping the 4 way handshake done by the previous station, and knowing the PSK), he will have trouble to inject frames: each frame have an anti-replay sequence number, and if the AP detects replays, it knows that there is an attacker somewhere. because CCMP is secure, the AP may choose to simply ignore detected replays, so, again, the first one to send a packet with an acceptable sequence number wins. And, in top of that, you also still have the ACK collision problem.

So if the attacker want to inject frames without disconnecting the other station, it need to be more smart : he may transmit frames at will, but should not acknowledge received frames, and must have a better link quality that the original station to not loose too many frames. The attacker's work is much simpler if he can use the same IP address but with a different MAC address, and ignore all ARP requests: he can inject IP data, and will miss half the received data (depending on its link quality), but will not degrade the connectivity of the other station in any way.

If he has to use the same MAC address, then he may inject frames only if the network is open, wait for the acknowledgment, and retry if the acknowledgment is not received, and hope that the previous station is not too confused by receiving acknowledgment when not expected. The attacker must still passively monitor the channel and will still miss a lot of the inbound data.

Attacking is hard, even if 802.11 make it easy.


And by the way, ifconfig and route are deprecated on linux. Use ip link, ip addr and ip route instead. Also, you can use ip link set wlan0 address xx:xx:xx:xx:xx:xx instead of macchanger :

#!/bin/sh
ip link set wlan0 down
ip link set wlan0 address ac:81:12:a2:4e:3a
ip addr add 192.168.1.5/24 dev wlan0
ip link set wlan0 up
ip route add default via 192.168.1.1
share|improve this answer
    
thank you for your answer. i really appreciate it. but i think i found the reason. –  george Feb 17 '13 at 0:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.