Wireshark mailing list archives
Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3
From: John Powell <jrp999 () gmail com>
Date: Mon, 13 Aug 2012 06:44:04 -0600
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 () lurchi franken de> 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 CentOS6.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 port1985 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.capMy users have told me that when they select a packet capture then selectTelephony - RTP - Show all Streams that it indicates packets are being lost.Src IP Src port Dest IP Dest port SSRC PayloadPackets 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 82858 (6.5%) 399.94 1.53 0.5 Xt.t.t.t 11488 u.u.u.u 40300 0x46810727 ITU-T G.711 PCMU 82957 (6.4%) 400.07 2.54 0.13 Xv.v.v.v 2240 w.w.w.w 57836 0x375E2DB2 ITU-T G.711 PCMU 82957 (6.4%) 399.99 0.18 0.1 Xa.a.a.a 25012 b.b.b.b 52376 0x2FF25BB2 ITU-T G.711 PCMU 82957 (6.4%) 400.05 0.2 0.09 XI have looked at the following for determining the cause for the packetloss 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 idlwai hiq siq43k 3586k:2090B 1549k| 0 0 : 0 0 |9212 17k| 0 1 972 0 030k 26k: 0 15M| 11M 0 :5054k 0 | 27k 47k| 6 2 884 0 00 0 : 0 17M| 11M 0 :5154k 0 | 27k 51k| 4 2 913 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 thecause 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 MichaelThanks 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
___________________________________________________________________________ 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:
- Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3 John Powell (Aug 10)
- Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3 Michael Tuexen (Aug 10)
- Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3 John Powell (Aug 13)
- Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3 Michael Tuexen (Aug 13)
- Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3 John Powell (Aug 13)
- Re: Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3 Michael Tuexen (Aug 10)