Wireshark-dev: Re: [Wireshark-dev] Malformed packet New dissector
From: "your highness" <zanash@xxxxxxxxx>
Date: Mon, 19 Feb 2007 15:37:08 +0100
On 2/19/07, Guy Harris <guy@xxxxxxxxxxxx> wrote:
your highness wrote:

> The skeleton of my code that is relevant to this issue is as follows:
>
> static guint
> get_condor_pdu_len(tvbuff_t *tvb, int offset)

At least in the current version of Wireshark, a get_pdu_len routine
takes three arguments, not two - the first argument is the pinfo
pointer.  That was changed at the end of October 2006; I don't know what
Wireshark release first had that change.

I am using version 0.99.4. Using three arguments results in failure of
dissection in this version. The following message is given:
Warn Dissector bug, protocol CONDOR, in packet 18: tvbuff.c:387:
failed assertion "tvb && tvb->initialized"


> static void
> dissect_condor_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
> {
>  tcp_dissect_pdus(tvb, pinfo, tree, condor_desegment, 3, get_condor_pdu_len,
>     dissect_condor_tcp_pdu);

As already indicated, that should be 4, not 3, as the length part of the
first 4 bytes, even though the length itself only takes 3 bytes (the 3
bytes after the first byte).

Right, I have modified this. Please refer to my previous email.


> I am using netcat to send files that contain Condor packets for my
> tests. Attached is a captured file that contains condor packets of 42
> bytes. The first packet that is tagged Malformed has 2 bytes in the
> first TCP packets (0x20 and 0x00) and 40 bytes in the second TCP
> packet.

I build a skeleton dissector for Condor, based on your code, with the
two changes in question (three arguments to get_condor_pdu_len(), a
fixed length value of 4 in the tcp_dissect_pdus() call, and, reading
your capture, I don't see any malformed packets.

A similar message as the above one is given in this case as well,
dissection fails.


The TCP segments in frames 4, 6, 8, 10, 12, 14, 16, and 18 have a bunch
of Condor packets in them; all but frame 4 also have a bit of the
previous TCP segment frame reassembled in.

After that things don't appear to work; that might be a bug in the TCP
reassembly code.  I've attached the source to my skeleton Condor
dissector in case anybody else wants to look at this.

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev