Wireshark User Guide

User Guide
Wireshark for IP tracing in 3G IP RAN

Author: Nguyen Vuong Quoc Thinh
Date: 03/04/2011
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction. XXXXX 2 | Presentation Title | January 2009
Contents
1. General Overview
2. Wireshark setting user guide
3. Capture in live network
4. Wireshark trace analysis
General Overview
1
Proprietary Use pursuant to Company instruction. XXXXX
4 | Wireshark user guide | April 2011 Nguyen Vuong Quoc Thinh
Wireshark: Pros vs. Cons
Pros:
Wireshark software is free download & capable of being run in any laptop
Easy to send the traces to anyone without having to convert the file format
Provides a simple but powerful display filter language
Cons
Wireshark can drop the captured packets
Out of memory when capturing large traffic volume
Some protocol stacks cannot be decoded by Wireshark (like Frame Protocol
over Iub)
Software bugs and its functionalities depend on laptop network driver & PC
Equipment installation
Mirroring option: Recommended
ETH card
RNC
Router
Lp/14, Eth/x
RJ45 (ETH cable)
Mirroring port
(if the router does not have Ethernet port, an Optical-Copper SFP is needed)
Lp/15, Eth/x
mirroring
Iux over IP
Iux over IP
Iub (IP link)
Iu-PS/Iu-CS
SGSN/MSC
PC
Ethernet
Fiber
UL & DL traffic from multiple GIGE interfaces can be captured
Equipment installation
Splitter option
RNC
Router
Lp/14, Eth/x
RJ45 (ETH cable)
Lp/15, Eth/x
Iux over IP
Iub (IP link)
PC
Ethernet
Fiber
Optical Ethernet
Converter
One way traffic from only one GIGE interface can be captured
Rx slot
RNC
Router
Lp/14, Eth/x
RJ45 (ETH cable)
Lp/15, Eth/x
Iux over IP
Iub (IP link)
PC
Ethernet
Fiber
Switch 6850 with
2 Optical Ports
(2 SFP)
Both UL & DL traffic from one GIGE interface can be captured
Rx slot
Rx slot
Check list
Confirm the type of fibers (SX/LX) and connectors (LC/FC/SC) needed
Mirroring option (recommended), check availability of
Mirroring capability of the access routers
The dedicated mirroring port must be configured
If the mirroring port is Gigabit Optical, need to have
A Copper Ethernet SFP
Or an Optical Ethernet converter
Ethernet RJ-45 cable
Laptop with Wireshark
Splitter option, check availability of
Optical splitters
10/100/1000Base-T to 1000Base-SX/LX converter or Omniswitch with
associated SFP
Ethernet RJ-45 cable
Laptop with Wireshark running
2
Wireshark setting guide
(whatever the Iux interface)
Software overview
Winpcap
Mandatory for IP sniffing on Laptop
Provided together with the Wireshark software
All archived Winpcap version can be downloaded on http://www.winpcap.org/
Stable version is 4.1.beta5 or 3.1
Wireshark
Wireshark version: 1.2.5 (or later), check http://www.wireshark.org
Installation tip: Install Wireshark in the default folder given by cmd.exe
Useful in case you need to run Tshark tool, provided with Wireshark
Windump
Windows version of the popular tcpdump tool
Used to capture the IP traffic with packet truncated size
Useful & robust for capturing live network traffic
Windump version 3.9.5, download from http://www.winpcap.org/
Installation tip: put Windump.exe on a reachable folder from CMD
How to check if Winpcap works well?
Winpcap works well means Wireshark/Windump can
see all available network interfaces on the PC (Gigabit Ethernet, WiFi Link, Generic Adapter)
capture the UE trace from Qualcomm modem/data card (needed to see Generic Adapter)
Workaround
Uninstall the current Winpcap & Install the recommended stable Winpcap version
Use another laptop PC (avoid Lenovo ThinkPad if possible)
Generic dialup Interface
Qualcomm USB Modem
Gigabit Ethernet Interface
From Wireshark: OK
From Windump: NOK No generic dialup
adapter => cannot
take UE trace on this
PC
PC setting for capturing in promiscuous mode
Capturing all traffic that the network card can
see (i.e. mirrored traffic)
Check capture packets in promiscuous mode in
Wireshark Capture Options
Configure a dummy IP@ for Local Area
Connection
Automatic IP@ configuration can also work under
many PCs
No tracing if there is a mismatch between the
speed on the PC & mirroring interface
(Fast/Gigabit Ethernet)
Device manager > Network adapter> Advanced >
Link Speed & Duplex
Auto Detect is recommended (default setting)
100Mbps/1Gbps & Full duplex is desirable (if the
auto detect does not work); the selected speed
depends on the speed on the mirroring interface
Force the mirroring port to the same speed as the network
interface card (NIC)
VLAN capture setup issue
With some PC/Network Interface Cards, you won't necessarily see the VLAN tags
in packets when capturing on a VLAN
Some workaround to disable the stripping of VLAN tags.
http://wiki.wireshark.org/CaptureSetup/VLAN
http://www.intel.com/support/network/sb/CS-005897.htm
Workaround does not necessarily work for every NIC type, so please use
another PC/NIC in order to not waste too much time
Wireshark: Quick Launch
icon start a new live capture
icon stop the running live capture
Launch the Wireshark application
Identity the capture interface (in our case, it is a Gigabit network connection)
Capture > Interfaces
This is the
one we used
to connect
with the RJ45
Wireshark Settings
Capture > Options
Select the right capture
interface (NIC card)
Specify only in case you
know exactly what you
want to capture (ex:
ether[70:2]=0x0014)
Check them if you want to
see the traces displayed
in real-time
Click start to capture the
traces
Check when capturing
mirrored traffic
Truncate the
captured packet
(ex: 120 byte)
Save the trace
while capturing
Save in multiple
files, scheduled by
capturing duration
or file size
Schedule to stop
capture
Basic, must-know
Advanced, useful
for live network
capture
Wireshark trace example
captured
messages
(time,
address,
protocol, info)
Protocol
stack of the
selected
message
This is the DISPLAY filter, for example,
tcp.analysis.retransmission to display only the
TCP retransmission messages.
Header +
Data coded
in hexa
Common display filters
udp / tcp / sctp / icmp / ranap / sccp / gtp => to display only the desired protocol
sctp && ip.src==10.2.4.9=> display sctp sent from the source having IP@= 10.2.4.9
sctp || tcp => display sctp or tcp message (both tcp & sctp will be displayed)
tcp.analysis.retransmission =>
display the TCP retransmission
message
tcp.analysis.lost_segment =>
display previous segment lost
vlan.id == 123 => display the
message having VLAN ID= 123
More about the filter expression,
go to Expression
Quick Analysis
Statistics > Flow graphs
Statistics > TCP stream graph
Analyze > Expert Infos
[Date and Time] & [Time of day]
Useful for checking the day and time of measurement
[Seconds Since Beginning]
Useful for checking trigger points and analyzing time-spans
[Seconds Since Previous]
Useful for inter-packet arrival time interpretation
Wireshark overview: timestamp format
Essential to display the time sequence graph to analyze the TCP traffic
Usage: detailed analysis of TCP flow control, ACK shapes, spot retransmissions and losses
Useful only with traces near to the TCP data source (FTP sever for DL or UE for UL)
Select a data packet (not ACK packet) and go to Statistics, then TCP time stream graph
and Time sequence graph tcptrace)
Zoom: click-left ; Unzoom: SHIFT + click-left
Find packet: CTRL + click-left on packet (packet will be highlight)
Move time or sequence number axis: click-right
TCP trace
Display instant throughput calculated by wireshark
Usage: throughput dynamics (bandwidth changes, etc)
Select a data packet (not ACK packet) and go to Statistics, then TCP time stream
graph and Throughput graph)
Throughput graph
Display TCP RTT: delta between segment and its ACK. Makes sense only at
sender side.
Usage: check E2E RTT (will include buffering time if applicable). Check RTT
versus packet losses (possible overflow). Check if TCP not filling up E2E buffers
(low RTT=HSPA RTT)
Select a data packet (be careful, not to choose an acknowledgement packet)
and go to Statistics, then TCP time stream graph and RTT graph)
RTT graph
Display in-flight TCP data: useful at sending side only.
Usage: follow dynamic of CWIN / In-flight data, versus packet loss
(buffer overflow)
Select a data packet (be careful, not to choose an acknowledgement
packet) and go to Statistics, then IO graphs)
In-flight data graph
Capture in live network
Things to know
3
How to capture in live network?
Just remind you about live
Volume of capturing traffic is BIG
Traffic rate can reach up to hundreds of Mbps
One or two minutes of capturing can generate 1Go trace
Normal Wireshark capturing ==out of memory after less
than 3 minutes
Not trivial to follow your individual call
How to capture on live?
Use Windump to capture the trace
Use Wireshark
1. Specify the capture filter to take only the desired traffic flow
2. Limit the packet size: truncate to take only the header of each packet
3. Save the trace on multiple small files
Use Windump to capture the trace
Options to be used with Windump
Windump D : display the interface
Windump i 2 F filter.txt s 120 C 200 w filename.pcap
Advantages
Low resources consumption while capturing (low probability of having packets dropped)
Take big trace with long duration, no out-of-memory issue
Interface number
Capture filter expression
Each Packet size (byte)
Each file size
(unit: 1Mo)
Trace file name
See next slide for filter expression
3.1 Example of capture filter design : From Ethernet stack
Filter IuPS User Plane trace of UE whose IP@ is188.45.9.195
The source IP@ 188.45.9.195 is coded in hexa as 0xbc2d09c3 (4 bytes), started from byte 66
Similarly, the destination IP@ 188.45.9.195 is coded with 4 bytes, started from byte 70
Pos: 66
Pos: 0 Pos: 16
Pos: 70
Pos: 74
Capture filter
ether[66:4]=0xbc2d09c3 or ether[70:4]= 0xbc2d09c3
Note: if VLAN cannot be
captured, filter becomes
ether[62:4]=0xbc2d09c3 or ether[66:4]= 0xbc2d09c3
3.1 Example of capture filter design : from UDP stack
Another option to filter IuPS User Plane trace of UE whose IP@ ==188.45.9.195 is
udp[28:4]=0xbc2d09c3 or udp[32:4]= 0xbc2d09c3
udp[32:4]= 0xbc2d09c3
Pos:0
Pos:32
Capture filter
To avoid VLAN tag capturing capability, the capture filter can be designed from UDP stack
(instead of Ethernet)
3.1 Specify the capture filter
Specify the filter string in the Capture Filter
How to design the filter?
Identify what you want to trace
User plane traffic of an UE (with known IP@) on IuPS,
FTP data only, traffic flow with VLAN ID tag
Identify where and how this information is coded
Hexa info in Wireshark trace
Write down the capture filter
ether[start_pos:byte_length]=0xhexa_info
Some common capture filters
User plane IuPS of an UE with known IP@
udp[28:4]=0xUE_IP_hexa or udp[32:4]= 0xUE_IP_hexa
Or with VLAN captured: ether[66:4]=0xUE_IP_hexa or ether[70:4]= 0xUE_IP_hexa
FTP flow only (ftp port + ftp-data port) (without VLAN)
ether[70:2]=0x0014 or ether[72:2]=0x0014 or ether[70:2]=0x0015 or ether[72:2]=0x0015
GTP trace (without VLAN): ether[42:1]=0x30
3.2 Limit the captured packet size
Advantages:
Truncate each captured packet from beginning to the
specified value
Having a small file trace: easy for storing & post-processing
Same feature as tcpdump or windump
This HTTP packet is truncated at 120byte
Be careful
Too small truncated packet will not contain
all useful header information
Truncate packet (without capture filter)
gives the same out-of-memory issue
Statistics infos (like data flow rate,
throughput) could not be obtained from
packet-truncated traces
Recommended value: 120 bytes
limit each packet to 120 bytes if you want
to take the whole IuPS traffic
3.3 Save in multiple small files
Advantages:
Recommended to name the trace before capturing
(specify the folder where to store the trace as well)
In case issue with Wireshark (out of memory), trace is
already saved
Take a lot of time for saving a big trace after capturing
Hard to stop capturing the trace with Wireshark on live
network
Avoid the out-of-memory issue
Ease to take trace on live network (with possibility
to schedule the capture)
Stop capture can be used to schedule the capturing
File name: Iu_PS_test1
Each file will be captured during 1 minute
And stop capturing after 10 files (10 minutes)
Wireshark trace Analysis
4
Packet loss detection
TCP trace
To detect the suspected packet loss & retransmission with TCP Wireshark, use
filters:
tcp.analsysis.retransmission,
tcp.analysis.fast_retransmission
tcp.analysis.lost_segment
TCP packet; seq no=123 (not relative sequence number)
TCP packet; seq no=123
TCP packet; seq no=123
The TCP packet with tcp.seq == 123 is sent twice by the UE
and these packets can be seen twice at sniffer 2. But at the
sniffer 3, we only see the retransmitted packet.
Useful to
determine the
network segment
having packet loss
SCTP trace (Iu, native Iub)
Compare the number of SCTP
heartbeat & heartbeat ACK
Loss of heartbeat packet
Telephony-> SCTP/Analyze this
Association -> Chunk statistics
Check the TNS duplication number
for SACK message
sctp.sack_number_of_duplicated_tsns
!= 0
=> loss of SCTP DATA packet
RTP trace (IuCS over IP)
Telephony/RTP/Stream Analysis
No RTP loss
Check UDP Flow throughput
Check UDP throughput on UE/IuPS UDP Iperf flow
Use Statistics/Conversation List/ UDP
to get UDP transfer statistics.
Determine the UL transfer throughput:
Wireshark does not give application
throughput which can be calculated
by:
App_Thr = Packets*pkt_size*8/Duration
Note: if limit packet size is applied,
no available statistics info
UE IP address
Server IP address
Throughput (Ethernet+IP+
Transport+App)
App_Thr 1.54 Mbps
Use Wireshark UDP Iperf trace (UE, IuPS, Gn, Gi, UDP server side trace)
How to compute the UDP Iperf loss rate?
Main ideas
3rd UDP pkt
Trace of UE UP
captured at IuPS
Loss can be detected with
UDP Iperf
UDP datagram ID, starting
from 0 this ID is incremented
at each UDP segment (used to
detect packet loss)
1st UDP pkt
2nd UDP pkt
Use Wireshark FTP trace at UE, IuPS, Gn,
Gi, FTP server
Retransmission is detected based on TCP
sequence number
Real sequence number is used instead of
relative sequence number (Edit/Preferences)
More than one packets with the same sequence
number retransmission
How to compute the TCP retransmission rate?
Main ideas
Unchecked relative
sequence number
seq no=3698364802 (not relative seq)
Sniffer 4
seq no=3698364802
tcp.seq == 3698556853
tcp.seq == 3698556853
TCP bad checksum problem
When the checksum is bad, the packet is rejected, thus retransmission
Check checksum at different network segment
Checksum at FTP server
(computed by Wireshark, the
one added in the packet)
Checksum at CE-
RNC (Iu-PS)
Checksum at UE side
0x3d28 0x3d28 [incorrect,
should be 0x6f48]
0x3d28 [incorrect, should
be 0x6f48]
0x3d1c 0x3d1c [incorrect,
should be 0x1623]
0x3d1c [incorrect, should
be 0x1623]
0x3d10 0x3d10 [correct] 0x3d10 [correct]
This is the checksum
computed by Wireshark at
CE-RNC side. It is different
from the one inside the
packet.
=>TCP checksum error was
happened from the FTP server to
the CE (on the Iu-PS interface).
The checksum errors are related to
the IP transmission errors such as
toggled, missing or duplicated bits.
This is the checksum value
inside the packet (added at
FTP server)
Thank you
1. This slide package is dedicated for VNTelecom folks!
2. If you want to reuse any part of this slide, please contact me before.
3. If you have any questions/comments, please address to me at
nvqthinh@vntelecom.org

Wireshark User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wireshark User Guide

Uploaded by

Copyright:

Available Formats

User Guide

Wireshark for IP tracing in 3G IP RAN

You might also like