Hi,
Le jeudi 14 janvier 2010 ￜ 16:13 +1100, Ian Schorr a ￜcrit :
> Hi all,
>
> I'm in the process of making some improvements to the NFSv4 dissector
> and running into some problems - hoping for some insight.
>
> I've never spent any time with the pinfo "flags.visited" flag, or any
> of the logic that takes Wireshark through multiple passes processing
> the same packet. In what sort of circumstances would
> pinfo->fd->flags.visited actually be SET?
>
> In this case I'm expanding the NFSv2/v3 "File handle snooping" logic
> to support NFSv4 as well. At a certain point, nfs_name_snoop_fh() is
> called. I'm finding that when this is called while processing NFSv4
> frames, the frame has already been "visited" and this flag is set.
> This causes a conditional to fail and none of the FH snooping code is
> run. However, this flag is FALSE when called by nfsv3.
>
The whole file is first dissected sequentially with
pinfo->fd->flags.visited set to FALSE.
The most common error for what you're seeing is that the code is inside
a if (tree) block, with the new packet list tree is null when loading a
file, before it was null only with colors disable.
You can test if it's the case by setting a filter like 'frame' and
reloading the file with CTRL R.
in packet-nfs.c a lot of:
if (fitem) ....
looks suspicious to me as a null tree ==> proto_tree_add_xxx return
null
Didier