Thanks!
I have tried out this functionality and it is wonderful. I (and several students of mine) have put it to use already.
Thanks again.
----- Original Message ----
From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Cc: mwreynolds@xxxxxxxxx
Sent: Saturday, October 21, 2006 5:26:26 PM
Subject: Re: [Wireshark-users] Method to accomplish the equivalent of "http.content_length > nnn"
Very good suggestions.
I have improved the http dissector to handle header fields that are integers
so in the latest SVN version http.content_length IS an integer and
filters such as
http.content_length>55 now works.
I have also added a new field "tcp.pdu.size" that is displayed in the
TCP expansion for all tcp frames that contain a PDU header.
This is displayed regardless of whether reassembly is enabled or not
and represents the PDU size as reported by the higher layer protocol.
This field is present for all protocols that use the
tcp_dissect_pdus() API to track packets.
Almost all protocols we support running over TCP use this API, except
HTTP and a few others.
So while this tcp.pdu.size does not show up for HTTP you do at
least have http.content_length
thanks for your good suggestions.
ronnie s
On 10/19/06, Marc Reynolds <mwreynolds@xxxxxxxxx> wrote:
> I have a periodic need to identify object downloads in http traces. This is
> easily accomplished by setting the display filter (http.response.code ==
> 200).
>
> Some traces, however, may contain large numbers of tiny and (for my
> purposes)
> inconsequential objects, so I would like to be able to additionally apply
> something like (http.content_length > nnnn) to return only the larger
> reassembled objects.
>
> This does not work, however, because (I believe) that Wireshark treats the
> value of http.content_length as a string, not an integer, so the
> "greater-than"
> functionality does not apply. Interestingly, the filter editor / syntax
> checker
> does let me build and apply such a filter, but the results seem random,
> returning a mix of http 200 frames whose content lengths are larger and
> smaller
> than the value of nnnn.
>
> Is there a way to accomplish what I am trying to do? Is there a reason that
> greater-than is allowed on non-numerical fields? Is there some way to
> leverage
> this which I am not seeing?
>
> Alternatively, is there any other way to accomplish something similar? For
> example, it would be great if there were a way to accomplish something
> logically similar to (tcp.reassemble_size > nnnn).
>
> The latter approach would actually be useful in several other cases I can
> think
> of, as well.
>
> Thanks in advance for any insights.
>
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
____________________________________________________________________________________
Sponsored Link
Mortgage rates near 39yr lows.
$420k for $1,399/mo. Calculate new payment!
www.LowerMyBills.com/lre
