When diagnosing a problem, Samba developers are likely to request a packet capture (or trace).
The best way to do this depends on the tools available on your system. It is often easiest to run the capture tool from the command-line, unless debugging a problem that requires complex capture filters to be set (to reduce the network trace). For more complex tasks the GUI based network tools, such as wireshark, may be easier for beginners to use. For most types of problems tracing can be done either on the server or the client. If tracing on the server puts too much load on the server system to reproduce the problem or results in a network trace that is too large, tracing from the client can be attempted instead. From the command line of the operating system type: (note: in the table below, replace FILENAME with the descriptive file name):
tshark -p -w FILENAME
tethereal -p -w FILENAME
tcpdump -p -s 0 -n -w FILENAME
If you're sure the problem is only related to SMB, you can filter the traffic based on the ports:
tshark -p -w FILENAME port 445 or port 139
tethereal -p -w FILENAME port 445 or port 139
tcpdump -p -s 0 -w FILENAME port 445 or port 139
In many cases the process is as simple as the following: from your client (e.g. Windows workstation), download and install wireshark (http://www.wireshark.org), launch Wireshark from the Windows "All Programs" menu list, start the capture, do the operation that causes trouble, stop the capture and send the trace to the developer working on your problem (or attach it or a URL to the saved trace file location to the bugzilla bug). For some type of problems it is also important that we see the beginning of the SMB connection. You can cause the Windows client to reconnect if you first kill the Samba server's smbd process which is servicing your client before starting the trace. You do not have to restart all of Samba. You can find out the smbd responsible for your client by running the tool smbstatus on the server.