[Bo Xu <xubo.leo@xxxxxxxxx>]

Hello Ronnie ,

 

          I feel very upset that i can't do the SRT statistic because this field is wrong .

 

          But I checked another trace file , the hop-to-hop looks fine , but still , the result looks strange . I have attached this file.

 

          Can we use another approach to do the Diameter SRT , for example , Sesssion ID ?   of course , CER ,DWR will use another approach :)

 

BR

Xu Bo

 

On Wed, Jun 2, 2010 at 1:51 PM, Abhik Sarkar <sarkar.abhik@xxxxxxxxx> wrote:

Hi Xu Bo,

While I agree that the SRT (and request response tracking in the Diameter dissector can be improved, for example to detect duplicates), I think there is something wrong with the requests in the capture.

When I wrote these two features, I had based the request tracking on the hop-by-hop identifier based on this description in the Diameter Base Protocol RFC (http://www.faqs.org/rfcs/rfc3588.html).

   Hop-by-Hop Identifier
      The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
      network byte order) and aids in matching requests and replies.
      The sender MUST ensure that the Hop-by-Hop identifier in a request


      is unique on a given connection at any given time, and MAY attempt
      to ensure that the number is unique across reboots.  The sender of
      an Answer message MUST ensure that the Hop-by-Hop Identifier field


      contains the same value that was found in the corresponding
      request.  The Hop-by-Hop identifier is normally a monotonically
      increasing number, whose start value was randomly generated.  An
      answer message that is received with an unknown Hop-by-Hop


      Identifier MUST be discarded.

However, most of the requests and responses in the trace seem to have the same Hop-By-Hop Identifier, which looks a bit strange to me and is what is causing the problem.

The hop-by-hop identifier seemed to be the best field to choose, in addition to the TCP endpoints of course, to measure SRT because the end-to-end identifier can be unique across multiple hops if proxies are involved and one would rather measure (in my opinion) SRT between two adjacent points to get a true picture instead of across multiple hops (if the trace is taken on a machine which sees both legs). 

I am sure someone else will have comments as well.

Regards,
Abhik.

On Wed, Jun 2, 2010 at 8:31 AM, Bo Xu <xubo.leo@xxxxxxxxx> wrote:

 

Hello Ronnie

 

   PFA :)  

 

BR

Xu Bo

On Wed, Jun 2, 2010 at 11:19 AM, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:

That looks like a bug in the Diameter protocol SRT.

Most likely it can not handle if the transaction id is "reused" so it
ends up matching a reply from one transaction with a request that
happened for a different transaction much later.


Do you have an example trace where this happens ?
If so I can fix that issue.


regards
ronnie sahlberg

On Wed, Jun 2, 2010 at 12:47 PM, Bo Xu <xubo.leo@xxxxxxxxx> wrote:
> Hello Guys ,
>
>   SRT statistic is a really fantastic function of Wireshark .  I am doing
> the Diameter SRT.  But the Output is really confusion
>
>   For this pcap file <nocaaa.tcpdump.201006021007.pcap> , i got such result
> :
> index    procedure         calls       MinSRT              MaxSRT     AvgSRT
> 1          Credit-control    3132       -123.-68142        0.17384
> 58897650236.50013
>
> It looks very strange about MinSRT/AvgSRT value , and btw : the unit is
> second ?
> My Wireshark version is :Version 1.2.8 (SVN Rev 32676)
>
> BR
> Xu Bo

> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe

Attachment: ismpdump.rar
Description: Binary data