[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lost of packets



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