Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [PATCH] Adding RTSE reassembly

From: "Graeme Lunt" <graeme.lunt@xxxxxxxxx>
Date: Sun, 24 Jun 2007 07:35:25 +0200
Checked in.

Reassemble.c new function as: 
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=22174

RTSE reassembly as: 
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=22176

I made a slight change so that the RTSE preferences are grouped under OSI.

Graeme


> -----Original Message-----
> From: Stig Bjørlykke [mailto:stig.bjorlykke@xxxxxxxxx] 
> Sent: 23 June 2007 16:59
> To: graeme@xxxxxxxxxxx; Developer support list for Wireshark
> Subject: Re: [PATCH] Adding RTSE reassembly
> 
> Den 23. jun. 2007 kl. 11.54 skrev Graeme Lunt:
> 
> > I *think* this can be made a bit more generic and just call  
> > dissect_ber_octet_string
> > to extract the data - this will cope better when subsequent  
> > fragments use
> > constructed octet strings.
> 
> Yes, this works for all my captures.
> 
> 
> >> Another feature with this patch is that the info column shows info
> >> from the RTSE content instead of SES "MAJOR SYNC POINT 
> (MAP) SPDU" :)
> >>  (p772-transfer-success.pcap)
> >
> > I like this, but I think we may be better using col_set_fence() to  
> > achieve
> > this consistently.
> 
> This will be a bit strange when the MAJOR SYNC POINT is in its own  
> frame.
> I suppose we get  Protocol "S4406,"  and  Info "Military ... | ".
> 
> 
> >> One disadvantage is that the last RTSE fragment always is 
> 0 bytes (no
> >> data).  Any idea how (and if) this can be fixed?
> >
> > I think we can do this by comparing the RTSE fragment size to the  
> > negotiated
> > checkpoint size (though there may be a better way?).
> 
> This will not work for messages where the last fragment has  
> "checkpoint size" bytes, which happens in about 1 of 3072 packages  
> when using 3k size. Of course, it will work in most cases :)
> 
> I also have some captures from Microsoft Exchange 2003 (from a  
> customer) which does not follow the 1k limits (the RTSE data segment  
> is 3051, not 3072 as it should be).  This messages will not be  
> reassembled correctly with your approach.
> 
> In your patch, if you have more than one RTSE fragment in one frame  
> (I have seen this in MS captures) you will have two (or more)  
> reassembled messages which is a bit strange.
> 
> 
> 
> Attached a patch to fragment.c with fragment_end_seq_next() to end  
> the fragmented data without adding an empty data fragment.  
> This will  
> still show a reassembled entry when receiving a message smaller than  
> the checkpoint size, but without the 0 bytes fragment.
> 
> Also attached a new patch for SES, PRES and RTSE which uses  
> dissect_ber_octet_string() and fragment_end_seq_next().
> 
> 
> -- 
> Stig Bjørlykke
> 
>