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