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

couple of messages in one frame

0

I wrote a dissector,

I found one packet which contains couple of different/indifferent messages inside it,

Can someone point on the problem ? Is this even a problem ?

I reassemble TCP packets...

This is the function of dissection: (FRAME_HEADER_LEN = 8)

static void
dissect_PROTOC(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
    //Reassembling TCP fragments
    tcp_dissect_pdus(tvb, pinfo, tree, TRUE, FRAME_HEADER_LEN,
                     get_PROTOC_message_len, dissect_PROTOC_message);

}

static guint get_PROTOC_message_len(packet_info *pinfo, tvbuff_t tvb, int offset) { / the packet's size is "length" + 4bytes of TYPESIZE + 4bytes of LENGTHSIZE + 256bytes of CONTEXTIDSIZE / return (guint)(tvb_get_ntohl(tvb, offset + 4) + CONTEXT_ID_SIZE + TYPE_SIZE + LENGTH_SIZE); / e.g. length is at offset 4 */ }

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");
/* Clear out stuff in the info column */
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)"));

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);
    offset += length;

}

}

asked 25 Feb ‘13, 06:18

hudac's gravatar image

hudac
61111317
accept rate: 50%

edited 26 Feb ‘13, 22:27


One Answer:

1

You're using tcp_dissect_pdus(), so your protocol runs atop TCP. This means that there is no guarantee that packet boundaries for your protocol will correspond to TCP segment boundaries, so there's no guarantee that they will correspond to IP packet boundaries, so there's no guarantee that they will correspond to link-layer packet boundaries.

Thus, you may get multiple packets for your protocol in a single TCP segment, or you may get a packet for your protocol contained in more than one TCP segment, or you might get arbitrary combinations of those, for example, a TCP segment with two full packets for your protocol followed by the beginning of a third packet for your protocol, and the subsequent TCP segment containing the middle of the third packet, and the subsequent TCP segment containing the end of the third packet, two more full packets for your protocol, and the beginning of the sixth packet.

answered 25 Feb '13, 11:00

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Thanks, but doesn't the wireshark suppose to separate in a situation like this?

In one reassembled packet (one line of the wireshark, one frame), I get 6 packets of my protocol.

example:

Frame ...

Ethernet ...

Internet protocol ...

Transmission control protocol ...

Hypertext transfer protocol ...

My protocol ...

My protocol ...

My protocol ...

My protocol ...

My protocol ...

My protocol ...


Did you mean like this, with your question ?

Thanks,

(25 Feb '13, 11:13) hudac

I don't know what you mean by "separate", but, if your dissector is written correctly, Wireshark should display something similar what you show in your example.

However, I'm not sure why "Hypertext transfer protocol" is in there. Is that an HTTP CONNECT request, so that the TCP connection starts out as an HTTP connection, and then switches to a tunnel for your protocol?

(25 Feb '13, 11:34) Guy Harris ♦♦

Separate: I mean that for each "My protocol" there will be a different frame, like this:

Frame 1702: ...

Ethernet II, ....

....

....

My protocol


Frame 1705: ...

Ethernet II, ....

....

....

My protocol


"Hypertext transfer protocol", that was an example, I'll give another one about the situation I'm talking about, in one frame, I have a lot of "My protocol", doesn't wireshark suppose to separate them into different frames?:

Frame 1702: ...

Ethernet II, ....

....

....

My protocol

My protocol

My protocol

My protocol

My protocol

(26 Feb '13, 22:18) hudac
1

No, Wireshark wouldn't do that, because there aren't separate frames. If, in a single Ethernet packet, there is a TCP segment containing multiple packets for your protocol, Wireshark cannot report multiple "Ethernet II" lines, as there's only one Ethernet header for all those packets. Wireshark is NOT supposed to separate them into different frames, because they're all in one frame.

(27 Feb '13, 00:30) Guy Harris ♦♦