arpspoof (dsniff) on Debian: can't get it to work

Discussion in 'Linux Networking' started by Pieter Thysebaert, Sep 24, 2003.

  1. Hello,

    even after reading the dsniff FAQ (specifically the bits on arpspoof) I'm
    still stuck attempting to actually poison some machine's ARP cache:

    I have 3 GNU/Linux machines : client (, attacker ( and
    server/gateway (

    the network is on eth1 on each machine, eth0 is a control network
    I have changed the default gateway on both client and attacker to,
    since I understand this is the ARP entry being attacked.

    However, when I issue arpspoof -i eth1 -t
    on the attacker, I get "couldn't arp for host"

    the tcpdump trace, listening on eth1 of the client gives

    18:22:44.659027 arp who-has tell
    18:22:44.659042 arp reply is-at 0:5:5d:34:25:a7
    18:22:44.659119 > bootp-#133 htype-#86
    hlen:219 hops:47 xid:0x801033c0 secs:6838 C: [|bootp] (DF)
    18:22:44.659149 > icmp: udp port 67
    unreachable [tos 0xc0]
    18:22:45.661103 > bootp-#133 htype-#86
    hlen:219 hops:47 xid:0x801833c0 secs:26899 C: [|bootp] (DF)
    18:22:45.661113 > icmp: udp port 67
    unreachable [tos 0xc0]
    18:22:46.671163 > bootp-#133 htype-#86
    hlen:219 hops:47 xid:0x801133c0 secs:6805 C: [|bootp] (DF)
    18:22:46.671171 > icmp: udp port 67
    unreachable [tos 0xc0]
    18:22:47.681177 > bootp-#133 htype-#86
    hlen:219 hops:48 xid:0x801033c0 secs:6804 C: [|bootp] (DF)
    18:22:47.681186 > icmp: udp port 67
    unreachable [tos 0xc0]
    18:22:49.651213 arp who-has tell
    18:22:49.651284 arp reply is-at 0:50:ba:be:3d:83

    I mean, don't the first two lines show that the attacker DOES arp for

    And what's with udp port 67?
    Should anything on the client machine actually be listening on port 67 for
    arpspoof to work?

    BTW this is dsniff 2.4b1 on a Debian GNU/Linux 3.0 installation.

    Pieter Thysebaert, Sep 24, 2003
    1. Advertisements

  2. First make sure that your network works fine without spoofing.
    Only if it is working properly go on with arpspoofing.

    According the FAQ, this error normally indicates that the target
    host is not in the same network as the attacker. Check with
    ifconfig your netmasks. They should be the same on all three
    machines for eth1 (I think you want to use here).

    BTW: what network have you assigned to the eth0 interfaces?

    It does arp but I can't see the spoofing here. AFAIK the spoofed
    ARP would look like the following in your case:

    arp reply is-at 0:50:ba:be:3d:83

    where the MAC address must be the MAC address of the attacker.

    BOOTP/DHCP, this is used to configure automatically the IP
    related data for hosts.

    In your case above client ask for IP
    configuration data. However doesn't answer because
    there is no related server running.

    However what puzzles me a little bit is that the BOOTP packet
    trace looks broken. It is not broadcasted, unknown/invalid
    HW type, hop count very high, secs since reboot greater 60.
    Verify with ethereal whether tcpdump displays this correctly.

    Nevertheless check network config on and disable
    BOOTP/DHCP if it is enabled.


    Ciao, Horst
    Horst Knobloch, Sep 25, 2003
    1. Advertisements

  3. Thanks for your reply,

    Horst Knobloch wrote:

    It worked without spoofing, and now works with spoofing too (see below)!
    I have figured out that the bootp packet thing is the way used on linux to
    determine the client's MAC (upon receiving the icmp response the client's
    mac is stored in the arp cache)
    Ok, from the source code (arpspoof.c) i take that if __linux__ is defined,
    the attacker gets the client's MAC address by looking at the response to
    the bootp packet (which, according to ethereal, is a malformed packet)

    However, in arp.c (arp_cache_lookup) it seems that only entries wrt eth0 are
    looked for in the cache, so my arp entry concerning a machine on eth1 is

    All seems right now: i have changed eth0 in the code to eth1, and indeed for
    most of the time the client's arp entry for the gateway is now poisoned!


    Pieter Thysebaert, Sep 25, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.