How to collect a network trace using Wireshark tool or by netsh.exe command
Article ID: CTX695239
Updated On:
Description
Guides
Wireshark guide
Here is a simple guide on how to collect a network trace using Wireshark -
Always open Wireshark as an administrator. As this will ensure that we can see the network adapters to trace from.
Post opening, verify that the list of interfaces are coming through as seen in the screenshot below:
To start a trace:
Select the appropriate interface(s) from the list and hit start from Capture -> Start or by clicking on the "Wireshark" icon first in the list
To stop the trace:
Hit the stop"Icon" or Capture -> Stop
To save the trace:
Go to "File" -> "Save As" -> Give name to the file and location you want to save it to and hit save.
To trace for a specific host (IP )
Before enabling the capture, go to Capture -> Options
Specify the capture filter here
In the below example you can see we are tracing only for one specific IP address - 192.168.1.1
Then, start the trace and stop once repro is completed.
Note: More information on libpcap syntax can be found here: https://www.tcpdump.org/manpages/pcap-filter.7.html
To start chained ring circular capture
Go to Capture -> Options -> Output (tab)
This is the GUI equivalent of tshark.exe command line option.
Here you have to select "Create a new file automatically" and then configure the corresponding options:
Choose "After" and select "megabytes" from the drop down, and type after reaching what size we should create a new file, in this case it is set to 500 MB.
We also selected the option of "Use a ring buffer with" and selected 2 files, so it will keep overwriting the same two files whenever it reaches the individual file limit of 500 MB.
In total, the two files 500 MB x 2 = 1 GB of trace file is the resultant output.
Alternatively, if you do not wish to maintain two files, you can always set the file to "1" and that way, it can keep only one file. It's just a choice based on requirements.
Netsh
Please use an admin CMD prompt to run the below commands as netsh.exe requires the administrator privileges to start/stop the traces.
Also note, if you are running netsh.exe for the first time, it is advised to dry-run it once to make sure the packets are successfully saved to the disk. As a dry-run test, start and stop the trace as a test, verify the trace file is more than 1MB in size. If it is exactly 1MB (1024KB), the trace did not capture the packets and you may need to run that again.
To start the trace:
Netsh trace start capture=yes report=disabled overwrite=yes tracefile=c:\temp\%computername%_network.etl maxsize=1024 persistent=no
explanation - the above command will start capturing a network trace on the c:\temp directory with the file name as "hostname_network.etl" here hostname will be replaced with the actual hostname of the machine. The trace file is set to 1024 MB and persistent is set to No, means the trace will not survive a reboot. Other options are explained below.
To stop the trace:
Netsh trace stop
e.g.
Note: Remember that when you start a trace let's say from the account that you have logged on to the machine, it would only allow you to retrieve the session from the same logon account.
e.g. if you have logged in as TestAccount1, and start the netsh trace, and if you login as TestAccount2 and try to run the stop command, it will report no tracing sessions.
So always remember to stop the sessions from the same logged on user account.
Options:
netsh parameters can be viewed by running the command - netsh trace start /?
Report -> Whether to generate CAB file
Value -> yes/no/disabled
Overwrite -> tells whether to overwrite the same file
Value -> yes/no
Tracefile -> path to the output tracefile
Maxsize -> specify the size of the output file in MB
Capture -> tells whether to capture a network trace
Value -> yes/no
Persistent -> Whether the tracing session continues across reboots ( useful for boot time traces if it's a persistent machine )
Value -> yes/no
Environment
In select circumstamces/scenarios we may require additional logging and information, multiple set of logs and/or information collected through private builds to identify behavior that helps us isolate the problem.
This software application is provided to you as is with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that: (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the software application be used to support ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the software application.
Issue/Introduction
The Importance of Network Packet Captures in Diagnosing Connectivity Issues
Collecting a network packet capture is a critical step in diagnosing connectivity issues, as it provides a detailed, real-time view of traffic flowing between systems. Unlike logs or high-level error messages, packet captures record the exact communication at the protocol level, allowing engineers to see what was sent, what was received, and where potential failures occurred. This data can reveal latency, dropped packets, retransmissions, misconfigurations, or security anomalies that may not be visible through other diagnostic tools.
For customers, packet captures help speed up resolution by providing concrete evidence of the problem. For engineers, they serve as an indispensable troubleshooting resource, enabling root cause analysis and reducing guesswork. By leveraging packet captures, organizations can improve accuracy in diagnosing network issues, minimize downtime, and enhance the overall reliability and performance of their infrastructure.
Additional Information
