Wireshark-dev: Re: [Wireshark-dev] Determining Cause for Packet Loss in Wireshark 1.8.1 running
From: Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxx> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
- Follow-Ups:
- References:
- Prev by Date: Re: [Wireshark-dev] DeviceNet dissector
- Next by Date: Re: [Wireshark-dev] DeviceNet dissector
- Previous by thread: [Wireshark-dev] Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3
- Next by thread: Re: [Wireshark-dev] Determining Cause for Packet Loss in Wireshark 1.8.1 running under CentOS 6.3
- Index(es):