Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] pinfo->fd->flags.visited and NFS

From: didier <dgautheron@xxxxxxxx>
Date: Thu, 14 Jan 2010 08:46:24 +0100
Hi,
Le jeudi 14 janvier 2010 ᅵ 17:37 +1100, Ian Schorr a ᅵcrit :
> Hi Didier,
> 
> On Thu, Jan 14, 2010 at 4:54 PM, didier <dgautheron@xxxxxxxx> wrote:
> > Hi,
> > 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.
> 
> You're right - if I first open the capture, filter (with "frame") and
> then reload, then looks like the flag is FALSE and the code block is
> executed.
> 
> This function itself never tests "if <tree or subtree>", and so far I
> haven't found a situation where any of its parent functions in the
> stack do this.  There's so little difference between what NFSv3 and
> NFSv4 dissecting is doing at this point, it seems unusual.  But I'll
> keep looking.  Thanks for the tip.
> 
> I'm still not clear on why your example is a problem though - what's
> the logic error in doing this test during an "if (tree)" block?
pinfo->fd->flags.visited is only FALSE the first time and the first time
tree is null... thus in
if (tree)
	if (!pinfo->fd->flags.visited)
		foo()

foo is never executed.

same with:

fitem = proto_add_uint( ...)
if (!fitem) return offset
offset = foo()
return offset

The bug could be a lot earlier though. 

The code you're looking at may not being called at all if a previous
function return a wrong offset when tree is null, or it could be in the
rpc code.

Didier