["Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>]

Hi list.

Attached are two patches.
First patch will finalize the tvbuffication of packet-smb.c in that it takes
care of the last
remaining old style transaction dissector.
This is the same patch as was posted a few days ago.

Second patch which applies ontop of previous one rewrites the
request/response matching
completely.
This applies for all smb commands.
the SMB dissector can handle any number of commands between a client and a
server where MID is reused.
The dissector can handle any number of replies to a command (big transaction
replies) and will point to the correct
request. However, the request packet will only point to the response_in
first response seen.
This patch also contain a major cleanup of smb_info_t and many redundant
variables have been removed
and I have seen the memory footprint reduced by approx 40bytes per packet
for smb captures.
This is a lot of the capture is 100.000 packets.

short description of new and imho much simpler request/response matcher
1, each client/server session is assigned its own unique conversation.
2, each conversation is assigned two hash tables, named matched and
unmatched.
3, in the unmatched table we store mid->smb_info for the last requests we
have seen.
4, if we see a new request we will store this requests mid->smb_info data in
unmatched.
if there were already a different request for this conversation/session with
an identical mid, then the
old mid->smb_info mapping is first removed from the unmatched table.
5, everytime we see a new response we check if we can find a request with a
matching mid in the
unmatched table. if we find one and we see that this was the first seen
response to that command
then we add both frame_req->smb_info and frame_res->smb_info to the matched
table. If this was not
the first response we only add frame_res->smb_info.

6, everytime we see an old packet we just check the matched table for
anything matching pinfo->fd->num


Please comment.
(It would be nice if there would be a way to determine at runtime whether
the dissector is executing as part
of ethereal or tethereal. The SMB dissector, as well as several other
dissectors, keep quite a lot of state between packets
in various tables and lists. Some of this state makes very little sense to
keep for tethereal since every packet will only be
visited once and never again (correct?).
It would be relatively easy to make the smb dissector drop most of the
state, and thus the memory requirement, if it knew
when it was running inside ethereal and when it was running inside
tethereal)

Attachment: smb_patch2.diff.gz
Description: GNU Zip compressed data

Attachment: smb_patch.diff.gz
Description: GNU Zip compressed data