I'm not about to tell you what or what not to like of course, but since there seems to be a little confusion on why I object to this post, I'll try to clarify (and I'll do it in a response to you because it seems obvious now that the OPs reality is too far removed from mine to make sensible communication possible).

I don't think there is any bad knowledge...The really bad guys already know what they're doing.

I completely agree with this, that was not the point of my criticism. My point was that the example given does not work very well and is very naive in it's approach to ARP poisoning. As such it is not instructive at all, but merely harmful and misleading.

To illustrate, I'll give a short overview on how ARP works (I trust you won't object, since you're "curious" :-): a networked computer(A) that wants to send an IP packet to an address on its LAN needs to know the MAC address of the interface (B) which holds that IP address. "A" therefore sends an ARP request to the Ethernet broadcast address (usually FF:FF:FF:FF:FF:FF), this is received by all interfaces on the LAN. The machine hosting "B" responds with a unicast ARP reply sent from it's own MAC address to the MAC address of "A". "A" then stores the MAC-IP pairing in its arp cache and uses it for future communications. Once the arp cache entry expires (the time for this is variable and depends on OS) it first sends an ARP unicast request to the MAC address which previously held this IP. If it doesn't receive an answer it starts again at the beginning. In code (and using Net::ARP, which of course one would never do because the OS does this kind of thing automatically), a sensible ARP exchange would look something like this:

# "A" has the address 192.168.42.42 and wants to find out the MAC addr
+ess corresponding to 192.168.42.100
Net::ARP::send_packet('eth0',                 # Device
                        '192.168.42.42',          # Source IP
                        '192.168.42.100',          # Destination IP
                        'aa:bb:cc:aa:bb:cc',  # Source MAC
                        'ff:ff:ff:ff:ff:ff',  # Destinaton MAC
                        'request');             # ARP operation

# "B" has this IP address and responds
Net::ARP::send_packet('eth0',                 # Device
                        '192.168.42.100',          # Source IP
                        '192.168.42.42',          # Destination IP
                        '00:ee:ff:aa:b1:01',  # Source MAC
                        'aa:bb:cc:aa:bb:cc',  # Destinaton MAC
                        'reply');             # ARP operation

# "A" now stores this MAC address in its arp cache, after expiry
# it would send a renewal request like this
Net::ARP::send_packet('eth0',                 # Device
                        '192.168.42.42',          # Source IP
                        '192.168.42.100',          # Destination IP
                        'aa:bb:cc:aa:bb:cc',  # Source MAC
                        '00:ee:ff:aa:b1:01',  # Destinaton MAC
                        'request');             # ARP operation
# "B" will reply same as above
[download]

Now, contrast that with the packet the OP is sending in his code (hint: look at the destination hardware address) and I think you'll begin to see what the problem is and how his code makes little sense.

The above explanation naturally leaves out a lot of detail, and there is actually a mechanism which uses gratuitous ARP packets for rapidly announcing a changed MAC to all participants of a local LAN. This mechanism is the reason why the OPs code does anything at all, but even there he's using the wrong type of packet, so it doesn't work well. Added to that, the timing is all wrong.

Performing a DOS or MITM attack via ARP spoofing is a real threat, (and a reason one should never transmit unencrypted sensitive information over a network that others can potentially access), but trust me, you don't do it by broadcasting spurious ARP replies every 5 seconds, it's just a little bit more complicated than that. What the OPs code can do under some circumstances is disrupt network communication between certain clients on a LAN, and it does so in a very dumb and easily detectable way. In other words, its only use would be for people who want to copy-paste it and vandalise the network they're on. Also, the code itself is simply copy-pasted from the Net::ARP docs and the documentation is mostly wrong. Does this seem like something you want to see posted on perlmonks again and again ?