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
61●11●13●17
accept rate: 50%
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,
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?
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
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.