On 2/19/07, Guy Harris <[EMAIL PROTECTED]> 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@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
