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

How to add extra dissected packets to info column when reassembling is on

0

I would like to add all of the dissected messages's type of my protocol Protoc to the Info column.

I'm enabling reassembling of tcp packets. So sometimes, as you can see in the picture, there might be couple of messages of my protocol in one reassembled pdu.

The problem is that only [TYPE A] is shown in the Info column. (I think wireshark.org cut it in this file, so believe me). I would like to put in the Info column something like: [TYPE A][TYPE B][TYPE C]

Is it possible ?

In order to put the [TYPE] I use the following code in dissect_PROTOC_message():

col_clear(pinfo->cinfo,COL_INFO);
col_add_fstr(pinfo->cinfo, COL_INFO, "%d > %d [%s]",pinfo->srcport, pinfo->destport, val_to_str(packet_type, packettypenames, "Unknown (0x%02x)"));

I know there is a problem, cause every time wireshark finds new messages of PROTOC, it do col_clear() again, and deletes all the past information.

I tried to get the PDU length and each time do col_append_fstr() myself. if I'm not exceeding the PDU length. but I think it doesn't work also, because of the same problem with col_clear().

Help would be helpful, thanks.

alt text

------------------------------edit---------------------------------------

I tried to add col_set_fence(), but it still doesn't work. for the next code, I get the next picture. please tell me if you need and further information.

static void dissect_protoc_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
/* my dissecting code */
guint32 packet_type = tvb_get_ntohl(tvb, 0);

col_set_str(pinfo->cinfo, COL_PROTOCOL, protoc_SHORT_NAME); /* Clear out stuff in the info column */ col_clear(pinfo->cinfo,COL_INFO); col_add_fstr(pinfo->cinfo, COL_INFO, "%d > %d ",pinfo->srcport, pinfo->destport); col_set_fence(pinfo->cinfo, COL_INFO); col_append_fstr(pinfo->cinfo, COL_INFO, "[%s]", val_to_str(packet_type, packettypenames, "Unknown (0x%02x)"));

if (tree) { /* we are being asked for details */ proto_item *ti = NULL; proto_tree *protoc_tree = NULL; proto_item *protoc_data = NULL; proto_tree *protoc_data_tree = NULL; guint32 type = 0; guint32 length = 0; gint offset = 0;

    ti = proto_tree_add_item(tree, proto_protoc, tvb, 0, -1, ENC_NA);
proto_item_append_text(ti, ", Type: %s", val_to_str(packet_type, packettypenames, "Unknown (0x%02x)"));
protoc_tree = proto_item_add_subtree(ti, ett_protoc);

//getting type
type = tvb_get_ntohl(tvb, offset);
    proto_tree_add_item(protoc_tree, hf_protoc_pdu_type, tvb, 0, TYPE_SIZE, ENC_BIG_ENDIAN);
offset += TYPE_SIZE;

//getting length for the data length
length = tvb_get_ntohl(tvb, offset);
proto_tree_add_item(protoc_tree, hf_protoc_len, tvb, offset, LENGTH_SIZE, ENC_BIG_ENDIAN);
offset += LENGTH_SIZE;
proto_tree_add_item(protoc_tree, hf_protoc_contextid, tvb, offset, CONTEXT_ID_SIZE, ENC_BIG_ENDIAN);
offset += CONTEXT_ID_SIZE;
protoc_data = proto_tree_add_item(protoc_tree, hf_protoc_data, tvb, offset, length, FALSE);
protoc_data_tree = proto_item_add_subtree(protoc_data, ett_protoc_data);

switch (type) {
    case TRANSCODE_ID:
                parse_transcode(protoc_data_tree, tvb, &offset);
                offset += length;
        break;
    case INPUTDATA_ID:
                offset += length;

…. …. ….

alt text

asked 03 Jul ‘13, 07:57

hudac's gravatar image

hudac
61111317
accept rate: 50%

edited 04 Jul ‘13, 01:50


One Answer:

0

Have a look at col_set_fence() as discussed in Sect 1.4.8 of README.dissector.

answered 03 Jul '13, 08:24

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

Thanks, I tried it now. But it still doesn't work. I'm not calling any subdissector - It's the same dissector. does it matter?

(03 Jul '13, 22:06) hudac

It does work, I've used it in packet-dnp.c. There may be multiple DNP3 PDU's in a single TCP/UDP frame and the info column reflects the basic function of each of the PDU's in the frame.

(04 Jul '13, 01:34) grahamb ♦

thanks, I'm looking at "packet-dnp.c", can you look into my edit?

(04 Jul '13, 01:53) hudac

I can't see any real difference...

(04 Jul '13, 02:03) hudac
1

You are setting the fence after adding the "from > to" info, so the packet type info isn't protected. I would have thought you would have seen multiple entries for the "from > to" and only the last packet type string.

set_fence clearly works for my dissector and others, so you'll just have to debug your issues.

(04 Jul '13, 03:13) grahamb ♦