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 < [email protected]> 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 <[email protected]> > > Archives: http://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:[email protected] > ?subject=unsubscribe > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
