Wireshark mailing list archives

Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3


From: Michael Tuexen <Michael.Tuexen () lurchi franken de>
Date: Fri, 10 Aug 2012 15:37:00 +0200

On Aug 10, 2012, at 3:14 PM, John Powell wrote:

Hi Everyone,
      • I am running Wireshark 1.8.1 (compiled from source) under CentOS 6.3.

      • I am running Dumpcap as a service.

Dumpcap command command line is:

/usr/local/bin/dumpcap -B 32 -i 2 -f vlan and (not vrrp and not udp port 1985 and not ether host 01:00:0c:cc:cc:cc) 
-b files:1200 -b filesize:250000 -b duration:900 -w /var/opt/data/captures/eth1.cap

My users have told me that when they select a packet capture then select Telephony - RTP - Show all Streams that it 
indicates packets are being lost.

Src IP    Src port Dest IP Dest port SSRC         Payload          Packets Lost           Max Delta (ms)    Max 
Jitter (ms)    Mean Jitter (ms)    Pb?
z.z.z.z    25000    a.a.a.a 58436     0x4E5B15A3   ITU-T G.711 PCMU  828    58 (6.5%)      399.94    1.53    0.5    X
t.t.t.t    11488    u.u.u.u 40300     0x46810727   ITU-T G.711 PCMU  829    57 (6.4%)      400.07    2.54    0.13    X
v.v.v.v    2240     w.w.w.w 57836     0x375E2DB2   ITU-T G.711 PCMU  829    57 (6.4%)      399.99    0.18    0.1    X
a.a.a.a    25012    b.b.b.b 52376     0x2FF25BB2   ITU-T G.711 PCMU  829    57 (6.4%)      400.05    0.2    0.09    X

I have looked at the following for determining the cause for the packet loss with no avail:

#dstat -dnyc -N eth1,eth2 -C total -f 5
--dsk/sda-----dsk/sdb-- --net/eth1----net/eth2- ---system-- ----total-cpu-usage----
 read  writ: read  writ| recv  send: recv  send| int   csw |usr sys idl wai hiq siq
  43k 3586k:2090B 1549k|   0     0 :   0     0 |9212    17k|  0   1  97   2   0   0
  30k   26k:   0    15M|  11M    0 :5054k    0 |  27k   47k|  6   2  88   4   0   0
   0     0 :   0    17M|  11M    0 :5154k    0 |  27k   51k|  4   2  91   3   0   0

# ethtool -S eth1
NIC statistics:
     rx_packets: 8993763019
     tx_packets: 48
     rx_bytes: 1966538225542
     tx_bytes: 8503
     rx_broadcast: 1123416
     tx_broadcast: 4
     rx_multicast: 84815150
     tx_multicast: 44
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 84815150
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 1966538225542
     rx_csum_offload_good: 3144430076
     rx_csum_offload_errors: 1488
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0

# ethtool -S eth2
NIC statistics:
     rx_packets: 3244021783
     tx_packets: 50
     rx_bytes: 697014132296
     tx_bytes: 8727
     rx_broadcast: 5279269
     tx_broadcast: 4
     rx_multicast: 18211478
     tx_multicast: 46
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 18211478
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 697014132296
     rx_csum_offload_good: 3110059283
     rx_csum_offload_errors: 0
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0
     rx_dma_failed: 0
     tx_dma_failed: 0


I would be most greatful for any suggestions as to how to determine the cause of this packet loss and resolve it for 
my users.
When dumpcap is terminated, it writes how man packets were dropped. This number is also stored in
the capture file. So if you load the capture file in wireshark and select Statistics/Summary, you
should see how many packets were dropped.

Unfortunately, capinfos doesn't report the number of dropped packets (yet).

Best regards
Michael

Thanks in advance for any and all assistance!

-John
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: