On Jan 21, 2010, at 2:48 PM, Kaul wrote: > Well, I solved the problem - but I still don't get why it's working. I've > copied what packet-vnc.c does: > After getting the conversation object, get the per-packet info. If none > exist, I create one and copy the protocol conversation state machine to it. > Then, I act upon the state *from the packet info*. Everything works > beautifully afterwards (attached changed code - mainly the addition in lines > 290-297 - which fetch the per packet information and use it.) > > I'd still be happy to understand why this works now (also as a lesson for > others).
I haven't looked at your code, but here is an explanation of my thinking when I wrote that tracking code in the VNC dissector a while back: - First of all, the VNC protocol messages are usually identified by a message type field in the packet. However, the messages that are exchanged at the beginning of a VNC session are not, which is where the conversation tracking comes in. It isn't perfect though, because the Wireshark capture could start at any packet in the startup or after the startup messages. That's why EVERY packet should have a type in it :-). - In the VNC dissector, the if(tree) checks are almost all gone now except for creating the main VNC protocol subtree. This is because so much has to be done on each packet, even if it isn't displayed, to keep track of the session state. A while back, I started putting if(tree) all over the place and it was getting ugly. - When Wireshark loads the VNC packets from disk/network and displays each one on the screen, the dissector (not have any if tree checks really) tracks the state that it expects the packets to be in (and does some sanity checks to see if what is there is what was expected). This state is tracked between packets with per conversation data structures. The state information, after being sanity checked, is then marked in each packet's data structures. That way, the user can click on any packet in any order and the VNC dissector will first check to see that the per packet data has been stored and use that to determine what state that packet belongs to. If we didn't do that, then the conversation state would keep advancing every time a packet was clicked on. This would be fine if the user clicked on the packets sequentially starting at the beginning and not skipping any. Most users don't do that though (and it wouldn't be very useful anyway in the GUI at least) :) Hope this helps. Steve ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
