This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Updating COL_INFO column after packet visited

1

I am writing a custom protocol dissector 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. The source channel ID from the first data packet and return ack can be used to create a source / destination channel pair which I want to use in the COL_INFO info column, for example "data packet from 3 > 7", however when the first packet is initially dissected I only know the source channel ID as I have not seen the ack containing the destination ID. This results in the Info column for the first packet only being able to show the source ID and not the destination ID as its unknown at the point the info is constructed, however subsequent packets after the ack is received can be displayed with the full source and destination channel ID data in the info column.

Is there anyway to go back and update the Info column of a packet, for example when its selected in the GUI and re-dissected, so I can correct the text based on the collected conversation data? I had hoped that the info column would be recreated each time the packet dissector function is run but now I realise that the packets cinfo pointer is NULL on subsequent dissector calls.

Surely this is not an unusual thing to need to do, i.e. update an Info column text based on information not necessarily available when dissecting an individual packet but amassed as a result of dissecting multiple packets in say a conversation.

Any help welcome, thanks.

asked 22 Oct '13, 08:32

Mike%20the%20TV's gravatar image

Mike the TV
26114
accept rate: 0%

Interestingly I notice I get different results depending upon whether the packets are dissected from a live capture or a saved file. From the saved file the final conversation data seems to get used when setting the COL_INFO column so I get the correct packet destination ID.

That said I have also seen consecutive live captures display the COL_INFO data differently. For example my protocol has an end of message marker which obviously only can be determined once the last packet is received, however for display I was setting the notification that the EOM was missing in the COL_INFO column of all packets in the message. Sometimes the first packet which is dissected in the protocol gets marked with the no EOM tag despite the message having an EOM, but the rest of the packets don't get marked with the no EOM tag, seeming to suggest that the cinfo field only goes NULL after some period of time thereby allowing some of the later packets info field to be updated with the correct error tags once the whole conversation has been processed.

On other captures however all packets, even the first, get tagged correctly, i.e. no rouge EOM errors.

At what point in the dissection process does the cinfo field become invalid and the text in the COL_INFO field read-only?

(24 Oct '13, 01:08) Mike the TV

One Answer:

0

Packets are only scanned secuentially on the first pass when column info (should) be written, subsequent visits to packets happens when they are vissible in the GUI basing coulmn info on that would be unreliably. Fist you get one info then you scroll down in the list and go back and something different is shown.

answered 24 Oct '13, 01:28

Anders's gravatar image

Anders ♦
4.6k952
accept rate: 17%

Thanks for the reply. So should I not be adding text to the COL_INFO column which can only be determined based on whole conversation data?

Should the COL_INFO column be limited to just data decoded from the current packet only in isolation?

How would you therefore 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 it to the protocol tree pane, and I do 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?

Also why do I sometimes see the correct information in the COL_INFO column which could only be determined from conversation data obtained from later packets if the COL_INFO field is only available for update when dissecting the packet on the first pass?

It also seems that the processing behaviour is inconsistent when you capture packets live compared to loading a capture from file, does the scanning work differently when loading from a file?

(24 Oct '13, 02:46) Mike the TV

Actually I don't think the packet processing in live captures is as straightforward as you say which may explain why sometime I see it generate the correct COL_INFO text.

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.

pkts 7-13 then get processed all with cinfo NULL the first time, then again with valid cinfo.

I am confused as sometimes it works, sometimes it don't?

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 10: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 11: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 12: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 13: 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
Pkt 10: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 11: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 12: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 13: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 12: Src chan = 4, dst chan = 0, cinfo = 0x00000000
(24 Oct '13, 03:50) Mike the TV

OK here's a time when it put unknown for the destination channel ID in the COL_INFO column for the first conversation packet.

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 31: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 32: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 33: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 34: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 35: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 36: Src chan = 4, dst chan = 0, cinfo = 0x00000000
Pkt 37: 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
Pkt 31: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 32: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 33: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 34: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 35: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 36: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
Pkt 37: Src chan = 4, dst chan = 0, cinfo = 0x3f9f9138
(24 Oct '13, 04:03) Mike the TV

I think it's better to ask this type of questions on the developper mailing list

(24 Oct '13, 05:25) Kurt Knochner ♦

I sort of thought this was. I'll go and look for that list instead. Thanks.

(24 Oct '13, 06:13) Mike the TV
(24 Oct '13, 06:53) Kurt Knochner ♦
showing 5 of 6 show 1 more comments