mcastClients

DHCP snooping can do different things dependening on how it's configured. It can prevent ARP spoofing attacks, or DHCP server exhaustion, by limiting the amount of source IPs that can ingress a given port on a switch. To prevent this program from doing its evil, DHCP snooping could be configured to only allow one source IP address on a port. In fact, to prevent this kind of attack you don't even need DHCP snooping. Since it requires MAC spoofing you can configure the switch to only learn one MAC on that port, or only allow frames with a limited number of MACs to ingress the switch. Hope this helps. A while back I wrote opensourced some code I wrote for work that emulated IGMPv2 behavior of triple-play set top boxes. It's meant to stress IGMPv2 implementations, but it also emultates multiple DHCP clients. https://github.com/smutt/mcastCli

I'm the author of hexcap(http://www.hexcap.org), an ncurses libpcap file editor and packet generator. I've also written many Scapy applications like this one(https://github.com/smutt/mcastClients). I rewrote the DHCPv4 client in Scapy since the stock one is broken. Also as part of hexcap have made numerous fixes to dpkt. Needless to say, I've done a lot with Python and packets. If you're interested in writing a TCP/IP stack in Python I would recommend you use Python raw sockets, or possibly dnet[1] or pcapy[2]. The Scapy level of abstraction is too high for your needs. I agree with other posters who mention buffering in libpcap. Read the man page for pcap_dispatch to get a better idea of how buffering works in libpcap. Also try capturing packets with tcpdump with and without the '-l' switch. You'll see a big difference if your pkts/sec is