hi, i was doing some tests and came across something that i don't understand. I was capturing a file download from a FTP Server. When I look on the very last packet from the sender it matches the size of the downloaded file - 2 bytes (for SYN / FIN packets). The same file i was uploading on a SMB share but this time the very last packet of the sender has a higher sequence number value than the file size itself ??? Relative Seq Number are enabled, it might be something simple but I'm puzzled ... any ideas please ? BR Adam asked 14 Nov '15, 14:40  adasko |
One Answer:
That's because the FTP transfer you looked at was a raw data transfer, meaning that it only transported the file content (the rest, like the get/put commands, is happening in a second session). SMB has additional protocol headers that are transported over TCP, and transfers the files in chunks (usually 64k). Look at your SMB packets and you'll see the headers - this is what takes additional bytes away from your sequence number calculation. answered 14 Nov '15, 16:50  Jasper ♦♦ edited 14 Nov '15, 16:50 showing 5 of 7 show 2 more comments |
Hi Jasper, thank you for your answer. I did no select the answer as the correct answer yet but the page says that i did it lol, strange.
I'm just wondering because in and older post i found the following "f you want to know only how many data bytes were transmitted, not including Ethernet, IP, or TCP headers, then make sure Wireshark's TCP preference "Relative sequence numbers" is enabled. (This is the default.) Go to the very last packet from the sender and see what the sequence number is. This is the total number of data bytes transferred."
https://ask.wireshark.org/questions/42834/calculate-the-number-of-bytes-sent-in-a-tcp-session
Is SMB an exception or am I still missing something ?
BR
Adam
b) is correct :-)
Think about "file contents" and "file description". As Jasper wrote, ftp uses a dedicated tcp session for transferring the contents of each file (hence the tcp sequence number of the last transferred packet matches the file contents size), and uses the common control tcp session to transfer the file name(s).
SMB, in contrary, transfers both the file contents and the file description (pathname and file name at least) in a single tcp session, so the number of transferred bytes includes not only the size of the file contents but also of the additional information.
SMB is a protocol carried over TCP (i.e., all the SMP stuff, including the SMP protocol headers, is part of the TCP data bytes).
So: as indicated by Jasper, the TCP sequence numbers (i.e., TCP data bytes) for an SMB TCP payload include both SMB protocol header data and SMB file data.
so to known the how many data bytes were transmitted in a SMB conversation I would have to sum the tcp length values ?
Your original question was suggesting that you were interested in the size of the contents of a single transferred file. This is possible with ftp where a dedicated tcp session is created for each individual file to be transported.
SMB, unlike FTP, uses a single TCP session to transport both the files' contents and the control communication, i.e. much more data than just the file(s) contents, like the initial login conversation, the file name and path, the timestamps of creation/last access/last write etc. So by tcp seq no, it is impossible to determine how many bytes the file contents alone has got. You would need to dive deeper into the SMB packets and sum up the SMB payload.
@sindy ok now i see. Ist there perhaps any query / filter I could use to sum up the SMB payload ?
The term "SMB payload" in usual understanding still means more than just the file contents.
But to answer what you really intended to ask, try
File -> Export Objects -> SMB
You should get a list of files with sizes. I don't have a SMB capture handy to verify this, however.