["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Ian Schorr"
Sent: Thursday, June 19, 2003 6:19 AM
Subject: [Ethereal-users] Server Response times


> Hi all,
>
> I find it exceedingly helpful when looking at SMB and ONC/RPC-based
> traffic to use the "smb.time" and "rpc.time" fields to look at server
> response times, and responsiveness of particular servers/applications in
> client/server interactions.
>
> I've been looking through other dissectors, like Kerberos, SNMP, HTTP,
> and others, and noticed that no such filterable field exists (in fact,
> I'm very surprised how few filterable options exist in many of these
> dissectors)

Some dissectors are very old.
Some dissectors are for protocols that are just not very popular and thus do
not generate much feedback for requests
for features or patches.
Most dissectors have not had the same TLC applied to them as the NFS and SMB
dissectors.


One problem with the SNMP dissector is that most of the SNMP data that is
displayed
are not dissected by hand-written code but instead through an extenal
library.
This currently prevents it from populating the middle pane with filterable
items.
There were discussions a week ago about a project to create/modify an ASN.1
compiler
to produce an ethereal dissector.
If this compiler would surface and would be capable of transforming a MIB
into an ethereal
dissector where everything had its own proper filter item.
This could then generate real ethereal dissectors for the more
common/popular MIBs
and be built into ethereal.
The SNMP dissector could be modified to recognize which objects have a
real dissector built into ethereal and which objects it would have to call
the (current) external
library that reads the mib and decodes the data.

This would go a long way to make SNMP and everything else that is encoded
using the
ASN.1 BER protocol much nicer.


>
> Am I just missing something?  Or does anyone have any suggestions on how
> to obtain this kind of information with filters (beyond the obvious -
> "implement the fields in the dissectors")?  Looking at TCP ack times,
> frame/record delta times, etc. are usually meaningless or potentially
> misleading when trying to measure server/application response times.

I have looked at SNMP and it would be easy to add a snmp.time  field and
ServiceResponseTime
statistics to ethereal for SNMP.
The only thing I need is a canonical list of which packet types are requests
and for each request type, which packet types are valid responses to those
requests.
I am too lazy to read the RFCs since SNMP is not really a protocol that
interests me much.
I guess that one valid transaction in SNMP could looks like:
 GET ->
 <- RESPONSE
And something that would not be valid would be
  GET->
  <-SET
To do the matching properly one would need a canonical list of all valid pdu
sequences for a single transaction.

If someone knows SNMP well enough to describe these valid sequences to me
I can add request/response matching  and service response time statistics to
ethereal.
I would need example captures as well as someone to discuss pdu sequences
with.



As for kerberos,   that would take a bit more work.
The only reliable way to match kerberos requests with responses would be to
look at the content of the
payload.
However (if i remember correctly) a lot of the payload is handled by the
external asn library in teh same was as snmp payload is and thus it is
difficult to get to it.
If the kerberos dissector is rewritten to explicitely decode the payloads
inside a proper dissector then it would
be possible to pick up the interesting fields from requests and responses
and do request-response matching.
Maybe the asn2eth tool would be able to generate a one shoot kerberos
payload dissector which could then
be hand edited/extended to start do more interesting stateful decoding of
kerberos.



>
> Thanks,
> Ian
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>