On Wed, Jan 26, 2005 at 11:44:21AM +0100, marc gmx wrote: > The counter "Packets In/Blocked" for interface bge0 indicate a value > of 124, WHY ???
One explanation would be that those 124 packets had invalid IP or UDP checksums. Before you assume that's impossible, check the output of $ netstat -sp udp $ netstat -sp ip before and after the test. If any non-obvious counter is increasing, that would be a lead. It might also help to capture all test packets on bge0 and bge1 with $ tcpdump -i bge0 -w bge0.pcap $ tcpdump -i bge1 -w bge1.pcap then run the test. You'll see all packets received on bge0 with $ tcpdump -nvvvXr bge0.pcap including those blocked by pf (as tcpdump using bpf gets them earlier). Now compare that with those packets that came out on bge1 (using bge1.pcap). You should be able to associate each outgoing packet with an incoming one, based on the destination address (which is unique in your test, if I understand correctly). If you find packets in bge0.pcap that have no corresponding entry in bge1.pcap, show us the full output of tcpdump -nvvvX for those packets only (one or two examples should be enough). If there are invalid checksums or IP options or other packet corruptions, we'll see it in the hexdump. I don't think this is related to the NATing at all. If there was a problem in the NAT code (like failure to allocate a proxy port, or similar), you wouldn't see packets counted as 'blocked in on bge0'. More likely, the perl script is not correctly setting the checksums in all cases, or there's corruption due to collisions or such. Daniel
