If you created a rather large tcpdump and are having issues with Wireshark taking forever.. then split your tcpdump into smaller files.
|
1 2 3 |
tcpdump -r old_file -w new_files -C 10 </code>This will read from large tcpdump files say 1.5GB..and create 150 10MB files called new_files{1..150}. Or do 100 for 100MB which will create ~15 smaller files. |
tcpdump -vvv -i eth0 -s 0 port bootps
(Copied from http://ask.wireshark.org/questions/4472/help-smb-troubleshooting)
You can go and start troubleshooting SMB in several way’s but there’s a lot of dark corners in that protocol! Here’s what i do first: 1.check if SMB version 1 is used (in SMB 2.1, loads of things have changed): You can find these values in the SMB negotiation part of an SMB conversation, right after the TCP 3-way handshake, use “smb.cmd == 0x72†which means filter on all “SMB Command: Negotiate Protocol (0x72)†to see what dialects the client is capable of. The last dialect listed, NT LM 0.12, is SMB 1.0.
And after see what client and server have agreed upon, find the response to this request (eg “Negotiate Protocol Response (0x72)â€) In short you can tell by only looking if the agreed upon value is SMB 1.0 by filtering on “smb.dialect.index == 5â€
if SMB 1, then look at the general flow of the conversation, by filtering on: a. filter on “smb” b. rightclick on a packet in the right stream and go “follow tcp stream”
with this filter you can then go and have a look at all the SMB service response Time statistics that matter for your conversation, by going: “statistics>service response time> SMB”
Here you can find wich command gives the largest delay’s , sort the rows, then right click and “prepare a filter” , use the filter (and save it for a rainy day) , f.i. “smb.cmd==50” Before you are all smb commands wich took the longest to complete, now mark ‘m all by ctrl+shift+M, then clear..
Now you can hop from marked packet to marked packet by using “ctrl+shift+N” to see what leads up to this command, or go and look inside of the packets and find out why a command is used.
Maybe you’ve already used the time sort column to find the same answer?
View>TimeDisplayFormat>SecondsSincePreviousDisplayedPacket, then doubleclick on Time Column and go back up and see the packets that took the longest (be aware that this depends on your filter (eg filter on smb and this TimeFormat means that large time difference you see is the time that passed since the last packet that matched your smb filter was seen!).
If i find something interesting i always go back to the tcp stream concerning to see what follows what exactly. This is just a start, after you find what packets cause the delays you might need to sort out the application, sort out reg files, and so on…
PS loads of this i’ve actually picked up from Joke Snelders, go and read her blogs on wireshark http://www.lovemytool.com/blog/joke-snelders/ great stuff!
In bash, remote capture is possible with the following command:
|
1 |
> wireshark -k -i <(ssh -l root remote-host dumpcap -w - not tcp port 22) |
The main problem is that you have to exclude the traffic generated by the ssh session from capturing. Several patches are available to do this, but excluding port 22 is probably the easiest solution for now.
The second problem is that ssh cannot ask for a password on stdin. You should either set up ssh-agent, or setup passwordless ssh keys , so that you don’t need a password.
This can be worked around by combining SSH with a FIFO, this is typically how I setup my sessions.
|
1 2 3 |
$ mkfifo /tmp/sharksess $ wireshark -k -i /tmp/sharksess & $ ssh user@remote-host "tcpdump -w - not port 22" > /tmp/sharksess |
