6333d9d7   
   From: m@rtij.nl.invlalid   
      
   On Sun, 06 Jun 2010 20:27:19 -0700, auxvivrespos wrote:   
      
   > I've recently been teaching myself about tcp/ip by exploring the traffic   
   > flowing across my computer's network interface.  I started by using   
   > tcpdump to view network traffic but found it difficult to read the   
   > output.  I switched to Wireshark and was overwhelmed by the amount   
   > traffic I had to sift through.   
   >   
   > To ease into things, I began by looking at only traffic related to IRC   
   > (internet relay chat).  I've observed that upwards of 50% of the packets   
   > are being flagged as "bad" by Wireshark.  These packets are duplicate   
   > ACK's and out-of-order packets.  It seems that ACK packets coming from   
   > the IRC are being repeated.  I'm not sure why this could be.  Inbound   
   > IRC packets also appear to be sent twice, with the second packet being   
   > labelled as out-of-order.   
   >   
   > As a comparison, I ssh'ed into a remote machine to which I have access   
   > and examined all IRC-related packets on that machine.  As I suspected,   
   > I'm not gettings these "bad" packets on this remote system..   
   >   
   > As for my physical setup here on my local system, my computer is sitting   
   > behind an integrated router/NAT/dsl modem which, in turn, faces the   
   > internet.   
   >   
   > At this stage my knowledge of tcp/ip is limited, but I'd like to   
   > understand why these packets which Wireshark flags as "bad" are showing   
   > up.  Can anyone provide any advice?   
      
   Well, well, you have a real world problem. Nothing better to learn from!   
      
   Some advice and observations.   
      
   0) What you most probably are seeing, is the results of packets being   
   dropped somewhere on the way from A to B.   
      
   1) That amount of bad packets is a sure sign of a problem. Some bad   
   packets are normal (even expected over longer distances), but this amount   
   not. My own rule of thumb is: <1% ignore, >2% sure problem. Others use   
   different numbers.   
      
   2) You currently only determined that there is a problem. What is causing   
   it cannot be said right now. You did the right thing by ssh-ing to that   
   other system, but that is only a start. Time for some analytical thinking   
   and breaking down the problem.   
      
   2a) Start by looking at other traffic on and from/to your home network,   
   see of the problem is not right in front of you.   
      
   2b) The way you describe your problem, what you see is the result of some   
   underlying problem. Try to reason out what the underlying problem is.   
      
   3) These kinds of problems can be caused by a lot of things. Of the top   
   of my head in order of relevance:   
      
   - Bad cable, connector or NIC (may be a NIC in a router/switch)   
   - Duplex mismatch (or some other setting, but that is rare)   
   - Overloaded link   
   - Overloaded end node (and you already ruled out the other end, if your   
   tests are repeatable)   
   - Overloaded router   
   - Duplicate IP address of nodes in the path with some other system   
   - Broadcast or some other storm on a (your?) LAN. (Where now down to the   
   very unlikely causes btw, you would have noticed this in other ways).   
      
   Note that as the Internet routes around problems, these problems may even   
   come and go, if they are somewhere on the intermediate nodes on the   
   Internet.   
      
   4) "Inbound IRC packets also appear to be sent twice, with the second   
   packet being labelled as out-of-order." This is not logical, they should   
   have been marked as duplicates. Duplicates are an indication of packets   
   in the other direction being dropped, which in itself is again a symptom   
   of the underlying problem.   
      
   5) Other tools to look at:   
      
   5a) Use tshark [-i intf] -w  [-b value] [-R displayfilter|   
   capturefilter] to capture over longer periods, then use tshark -r   
    -R  -w  to extract interesting portions and   
   have a better look at those in wireshark.   
      
   5b) hping can be used to ping and/or trace using tcp (and many other   
   protocols) in case icmp gets routed/treated differently from the problem   
   traffic.   
      
   5c) Don't forget ordinary ping and traceroute! Especially if you increase   
   the packetsize, you sometimes can show where the packet losses occur on   
   the route (but don't forget, routes on the Internet can (and do) change   
   any time)   
      
   HTH,   
   M4   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)