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