[David Bilsby <dbilsby@xxxxxxxxxxxxxx>]

Hi
    Apologies in advance if this is not the correct place to post this 
but I originally tried ask.wireshark.org and was pointed here instead.

    I am writing a custom protocol dissector plugin for our protocol 
layered on top of UDP. From the protocol header I can determine various 
packet attributes which allows me to group the packets into 
conversations of related data and ack packets.

    As part of the protocol header I have a source channel ID which I 
extract and store in the conversation. Unfortunately there is no 
destination channel ID in the packet so I have to infer this when the 
ACK packet is returned. That seemed to work fine as I then stash this 
away in the conversation. I then use these channel IDs to set a string 
in the COL_INFO column, for example "data packet channel 3 > 7", or "ACK 
packet channel 7 > 3".

    This seemed to work OK but then sometimes I would notice that the 
first packet would have my undefined channel init value set, -1, but 
subsequent packets would be fine. This did not happen ever time however.

    From comments on the ask.wireshark.org list I now realise that the 
COL_INFO column is only settable on one call to the dissector, so code 
which I assumed was rewriting the COL_INFO column to put the correct 
destination channel ID in was never actually doing anything because the 
cinfo structure pointer was NULL. However as I said the wrong COL_INFO 
did not happen every time. It never seemed to happen on dissecting 
captures stored to file and only sometimes on live captures.

    I added some debug to my dissector in my set_info_column_summary() 
function which I call on every packet after the 
update_conversation_data() function. This latter function is the one 
which determines the src and dst channel IDs from my packets, each 
packet only containing the src channel ID, therefore to get the full 
src/dst pair the conversation update function must have seen the first 
and second (ACK) packet in each conversation. This src/dst pair is used 
to set the channel IDs in the COL_INFO column.

    pkt 5 is the start of a new conversation. From its packet I can 
determine the src chan as 4, dst chan is unknown -1. Interestingly cinfo 
pointer is NULL. pkt 6 is the ACK reply which gives us the dst chan ID 
of 0, again the cinfo field is NULL. pkt 5 and 6 then get dissected 
again with a valid cinfo and by now I know both src and dst channel IDs 
so the Info field gets set correctly so the COL_INFO text is correct. 
pkts 7-9 then get processed all with cinfo NULL the first time, then 
again with valid cinfo.

Pkt 5: new conversation
Pkt 5: Src chan = 4, dst chan = -1, cinfo = 0x00000000
Pkt 6: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 5: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 6: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 7: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 8: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 9: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 7: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 8: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 9: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138

    When it does not work I get packet debug as below. Here pkt 27 is 
the first packet in a conversation and gets dissected first without 
cinfo set, then again with cinfo set but before I have seen pkt 28 which 
defines the destination channel. Hence this time the COL_INFO text is wrong.

Pkt 27: new conversation
Pkt 27: Src chan = 4, dst chan = -1, cinfo = 0x00000000
Pkt 27: Src chan = 4, dst chan = -1, cinfo = 0x3f9f9138
Pkt 28: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 29: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 30: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 28: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 29: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 30: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138

    Is this variation in the order in which the packets are dissected 
expected?

    As it is not possible to rely on a subsequent packet having been 
dissected and therefore set data in a conversation would I be right is 
thinking that the COL_INFO column should be limited to just data decoded 
from the current packet being dissected?

    If that's the case how would I for example alert a user to packets 
making up a bad conversation if it's not possible to update the COL_INFO 
column after processing the packets on the first pass, at which time you 
may not know if the conversation is bad? I know you can add expert info 
data to the protocol tree pane, and I do that also, but having to scroll 
through each packet to see when a conversation is bad would be a pain, 
the COL_INFO column seems to naturally provide a nice summary area to 
indicate this?

    I may be approaching this dissector writing all wrong and if so 
please excuse the potentially dumb questions, however I did read in 
depth the README.developer file and several other dissectors though I 
had a reasonable handle on how to structure this.

Thanks


begin:vcard
fn:David Bilsby
n:Bilsby;David
org:TEK Microsystems Ltd;Engineering
adr:Willow End Park, Blackmore Park Road;;Unit A Malvern View;Malvern;Worcs;WR13 6NN;UK
email;internet:dbilsby@xxxxxxxxxxxxxx
title:Principal Engineer
tel;work:+44 1684 311113
x-mozilla-html:TRUE
url:http://www.tekmicro.com/
version:2.1
end:vcard