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-requ...@wireshark.org?subject=unsubscribe