Re: [Wireshark-dev] pinfo-fd-flags.visited and NFS
Thanks gentlemen. That makes sense (Guy), and that's more or less what the problem was (Didier). Unfortunately it isn't quite as simple as an errant (tree) check encapsulating the call to me code, but they are problems that are dependent on the tree being present. I've found four bugs so far, and there's at least one more. Mostly they're problems where tree not being set causes some variable not to be initialized, and eventually that causes some problems where offset isn't incremented (sort of like your second example, but not exactly - the code's explicitly not doing certain things to increment the offset, not a situation where offset isn't returned properly). That leads to problems that eventually cause packet dissection to abort before it gets to my code - but only on the first pass dissecting the packet. Oddly, one bug was triggering an explit ASSERT but Wireshark is printing nothing to the console. Anyway, I've fixed all the bugs that are affecting processing of the NFSv4 replies I've been working with - now I need to work through the bugs affecting the calls. Fortunately the bugs aren't my code =) Thanks, Ian On Thu, Jan 14, 2010 at 6:46 PM, didier dgauthe...@magic.fr wrote: 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 dgauthe...@magic.fr 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 ___ 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 ___ 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
Re: [Wireshark-dev] pinfo-fd-flags.visited and NFS
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
Re: [Wireshark-dev] pinfo-fd-flags.visited and NFS
Hi Didier, On Thu, Jan 14, 2010 at 4:54 PM, didier dgauthe...@magic.fr 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? Thanks, Ian ___ 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
Re: [Wireshark-dev] pinfo-fd-flags.visited and NFS
On Jan 13, 2010, at 10:37 PM, Ian Schorr wrote: 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? Does the test affect either 1) the dissection of the current frame (e.g., what subdissectors are called); 2) the dissection of any future frames (e.g., does it update any state information); 3) any statistics/tap information? If so, then doing it inside if (tree) is wrong because there's no guarantee that it will be called on any particular dissection of the packet other than 1) dissections done to generate a protocol tree for display; 2) dissections done to generate a protocol tree for a packet filter. ___ 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
Re: [Wireshark-dev] pinfo-fd-flags.visited and NFS
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 dgauthe...@magic.fr 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 ___ 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
