Re: pinfo->fd->flags.visited and NFS

[didier <dgautheron () magic fr>]

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


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe