Wireshark-users: Re: [Wireshark-users] Method to accomplish the equivalent of "http.content_lengt
From: Matt Reynolds <mwreynolds@xxxxxxxxx>
Date: Fri, 17 Nov 2006 17:00:46 -0800 (PST)
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
- Prev by Date: Re: [Wireshark-users] TCP keep -alives
- Next by Date: [Wireshark-users] Interpreting the difference graph for a VoIP call
- Previous by thread: Re: [Wireshark-users] problem with display filter
- Next by thread: [Wireshark-users] Interpreting the difference graph for a VoIP call
- Index(es):