ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] about wireshark SRT statistics confusion

From: Bo Xu <xubo.leo@xxxxxxxxx>
Date: Wed, 2 Jun 2010 15:02:15 +0800
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