osmocom
/
wireshark
14
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity

the mid values in smb are too unreliable for request/response matching since they wrap so quickly. 

This has the effect that if you have a capture file with a hole in it, sa say when snoop or similar stops capturing packets for a while while writing the data to disk   you often end up with a packet just after the hole that is a response packet  and which ethereal mistakenly matches with a request/response from before the hole.


now,  when the first response is seen to a request   remove the entry from the unmatched table so that no other response can match the same request.



svn path=/trunk/; revision=12770
This commit is contained in:
Ronnie Sahlberg 2004-12-19 03:19:53 +00:00
parent 5d1b339131
commit 7def0aa70c
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
epan/dissectors/packet-smb.c
View File

@ -14777,6 +14777,19 @@ dissect_smb(tvbuff_t *tvb, packet_info *pinfo, proto_tree *parent_tree)
new_key->frame = sip->frame_res;
new_key->pid_mid = pid_mid;
g_hash_table_insert(si->ct->matched, new_key, sip);
/* We remove the entry for unmatched since we have found a match.
* We have to do this since the MID value wraps so quickly (effective only 10 bits)
* and if there is packetloss in the trace (maybe due to large holes
* created by a sniffer device not being able to keep up
* with the line rate.
* There is a real possibility that the following would occur which is painful :
* 1, -> Request MID:5
* 2, <- Response MID:5
* 3, ->Request MID:5 (missing from capture)
* 4, <- Response MID:5
* We DONT want #4 to be presented as a response to #1
*/
g_hash_table_remove(si->ct->unmatched, (void *)pid_mid);
} else {
/* We have already seen another response to this MID.
Since the MID in reality is only something like 10 bits