I am a computer engineer student. Recently, I was able to arp-spoof the router of my class.

I used:

  • Kali
  • Ettercap
  • Wireshark
  • The gateway IP address was:
  • The victim was my phone with the IP:

I was able to see the packets from my phone being sniffed by wireshark on my laptop.

However, I tried using the exact same method on the residential campus network.

  • Kali
  • Ettercap
  • Wireshark
  • The gateway IP address was:
  • The victim was my phone with the IP:

But I doesn't work. The only things that I can sniff on wireshark is the arp packets (Like: is at ec.a5.sd. ...

I think this is because the network is larger and have several layers. But I am not sure, why the arp poisoning is not working on the campus network?

enter image description here

  • Are they both connected to the same (wireless I assume because... phone) network? If so, maybe the network is heavily segregated into VLAN ranges to prevent this exact thing. – MiaoHatola Mar 5 '17 at 16:49
  • Sure they are both connected on the same wireless network – TSR Mar 5 '17 at 16:52
  • Could you try a traceroute between them? See how many jumps are in the way. This way you can get a sense for the structure of the network. Maybe add the result to the original post. – MiaoHatola Mar 5 '17 at 16:55
  • I don't recommend using those tools on a network you aren't authorized to do so on. Also see security.stackexchange.com/questions/20147/… – Ijustpressbuttons Mar 8 '17 at 0:26

There are a couple of possible answers; you don't provide enough information to determine the cause.

One cause might be that the active network components of your campus network are taking precautions against arp spoofing. The simplest one might work like this:

  1. Your phone talks to the network, maybe to fetch a webpage or something.
  2. The AP remembers where the first arp request from your phone for the gateway came from (Where is Tell 11:22:33:44:55:66, e.g. your phone's mac address).
  3. You're trying to spoof 11:22:33:44:55:66 from your laptop, but now the origin doesn't match the origin recorded by the AP in step 2, and so it doesn't update it's arp lookup table.

I know this kind of defense against arp poisoning can be used on switches (they remember which port a mac address lies on and can be told not to update their 'memory') and on normal computers.

I'm not sure how it would technically work on a Wifi AP - maybe a mac address can be tied to an active session on the AP. But I'm pretty sure it's something a professionally managed network would try to protect itself against, so it's not so surprising that it doesn't work in your campus network.

| improve this answer | |
  • please the the screenshoot that I added above, I hope it will help you understand my issue – TSR Mar 5 '17 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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