I'm studying ARP poisoning and I've coded a computer program to poison other computer's ARP cache using raw sockets in C language.

What I've done was: send an ARP reply to the target, always using another computer different from the target one, "telling" him that its gateway has my MAC address.

I don't want to act like a man in the middle. I just want to "turn the target off" of the internet.

I've tested in three LAN. I got success on two of them, that is, when I send an ARP reply to the target, I can't surf the internet with the target browser (I have access to it, so I can test it).

But, there is one network (a more complex one) that I failed to poison the target ARP cache. I have access to target computer, so when I send an ARP reply to it (using another computer), I check its ARP cache out, and the MAC address of its gateway is still the correct one, and more: I can surf the internet with the target browser. I don't know why it happens only to this network.

At first I thought it was some kind of static ARP, or something like this. So I used ettercap (and wireshark) to help me. I used ettercap's option of man in the middle with ARP poisoning and I got it. I could poison target's ARP cache with ettercap. I've "debugged" the ARP reply (using wireshark) that my computer program sent to the target and it is the same ARP reply that ettercap sent to the target.

Both network I got success are a wireless network. The one I got failed is a wired network.

Can someone help me with this problem? Why does it happen?

An observation: I don't want to start poisoning computers' ARP cache. I'm only studying some protocols more deeply, not only the theory. That's why I wonder why I can't poison ARP cache inside this network and ettercap can.


1 Answer 1


Depending of the device, they may send who-has ARP request every Xs. (or in case they think they've lost connection with your router)

This will result in your router giving back the correct mac address and the ARP cache of the victim will not be longer compromise.

To counter that, you can sniff your network (eg using scapy) to check for ARP request incoming from your device to send a new ARP is-at answer and keep the cache compromised. You can also re-comprommise the cache each seconds if you don't want to implement a sniffer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .