This problem is present even in Rev 22399. I recalled a change to the hashing technique by Rev. 22065.
Reverting that change fixes the hash clash for this particular instance but this rev was put in because of hash conflicts in other cases. Looks like the current hashing technique still needs some tweaking. Shehjar Sync ma wrote: > I am confused about the nfs packets, please take a look at frame > 137,138,139,140. > > frame 137 was a NFS Lookup call, request > libuClibc-0.9.28.so(DH=0x0794a104), in frame 138,139,140 wireshark > print the FH as 0x0794a104(same with the DH). > > I have tested the same pcap file in 0.99.5 on RHEL5, and it works > correctly(maybe not, at least it shows a different FH value to DH). > > BTW: for the same frame 137: > > DH value was 0x1bfc5524 in 0.99.5 on RHEL5 > DH value was 0x0794a104 in 0.99.6.a on Windows. > > both of the versions shows the 'dir/hash' value(copy bytes(hex offset)) : > > 0000 01 00 00 01 00 fd 00 00 e5 9a 62 00 e7 9a 62 00 > 0010 04 69 a6 91 00 00 00 00 00 00 00 00 00 00 00 00 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
