Using tcpdump shows that:

2182 packets received by filter
1983 packets dropped by kernel

Why is it dropping so many packets? Is there a way I can tell which packets are being dropped? I tried using the -j LOG, but it's still not telling me what packets it's dropping.

iptables -A FORWARD -j LOG <-- that syntax is correct or should I use something else?

I tried finding documentation on --log-level but I haven't been able to find any. I don't know if 0 or 255 is more verbose, I've tried both.

Any help or links would be much appreciated. Thanks in Advance.

Blindsight,

tcpdump and iptables are two different entities. tcpdump should be getting what is coming over the wire (before iptables gets a hold of it). The kernel is not able to deliver the packets to tcpdump. How fast is your network vs. your machine? What is the load on the machine?

Hope that helps,
chris

network = 10mbit
machine = 486/66 w/ 8mb of RAM

has a 15 minute average load of .01

This should be plenty to route and NAT for 3 machines on my LAN.

Also, I understand tcpdump and iptables are not the same. My question was, why is tcpdump saying it's dropping a buttload of packets? The only reason I had iptables in there at all was that I was trying to log these dropped packets in the hopes it would help me solve the mystery.

TCPDump can't keep up with the network speed, read the machine isn't speedy enough to process all the packets on the wire - RAM is the issue not a the speed of the processor - your sniffer is a layer 2 (data link) packet analizer, for it to be able to process all the packets coming on thewire it needs place to buffer them, and 8 Mb isn't enough so it tries to swap memory using HDD - memory paging concepts - I bet your HDD is from the era of 486 computing which has a huge latency factor - that's why the pockets dropped.

Blindsight,

The tcpdump man page explains the message. The kernel has a buffer for packets to be delivered to tcpdump. If tcpdump doesn't respond quickly enough, the kernel will overwrite old packets with new ones. I believe the key would be getting tcpdump to go faster.

What options are you passing to tcpdump? Are you writing to a file? I'm pretty sure tcpdump loses packets when it has to do DNS lookups, no matter what the speed of the machine. I also seem to remember tcpdump not being able to process all the packets when I had a 486 running Linux, but that was years ago.

Good Luck,
chris

neo777777 and bastard23; that was exactly the answer I was looking for and makes perfect sense.

And in looking in the man page of tcpdump, I feel like a boob. Thanks for pointing that out, bastard23 =)

Thanks again.