Why might an attacker keep arpspoof running in the background and also enable ARP poisoning inside Ettercap — two tools that seem to do the same thing?
Ettercap sends forged ARP packets at a lower frequency than arpspoof. On its own, Ettercap's slower refresh can let cache entries lapse and cause dropouts, so running both tools "bombards" the victim and keeps the poisoning rock-solid.
The division of labour:
| Tool | Role in the attack |
|---|---|
arpspoof |
Aggressive, high-frequency ARP flooding — keeps the poison fresh |
| Ettercap | The actual payload engine — runs the dns_spoof plugin to forge DNS replies |
Why not just Ettercap?
Ettercap can do ARP poisoning by itself, but it re-sends forged ARPs less often. Because ARP caches time out, a sparse refresh occasionally lets the real gateway MAC creep back in → the victim's connection flickers or the MitM briefly drops. Pairing it with arpspoof's faster flood removes those gaps.
Why not just arpspoof?
arpspoof only poisons ARP — it has no DNS-forging capability. You still need Ettercap (or similar) for the dns_spoof step that redirects mycampus.hslu.ch to your server.
The takeaway:
A reliable MitM often layers tools: one to hold the position (continuous ARP poisoning) and one to act on it (DNS spoofing, sniffing, content filtering). Reliability matters because a single dropout can tip off the victim.
Tip: This is also why detection works — two tools both hammering ARP onto the wire produce an obvious, high-rate stream of gratuitous ARP replies that tools like arpwatch or a switch's DAI flag immediately.
Go deeper:
ARP spoofing (Wikipedia) — why forged ARP replies must be re-sent continuously and how that becomes detectable.
Ettercap (Wikipedia) — the toolkit doing the dns_spoof payload while arpspoof holds the position.