[John Powell <jrp999@xxxxxxxxx>]

Hi Michael,

Thanks for the tip.

When I load up the PCAP file in Wireshark and look at Statistics Summary there is now indication of the number of packets lost.

Could you point me to what I am doing wrong?

Thanx,

John

On Fri, Aug 10, 2012 at 7:37 AM, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:

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@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

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