Re: [Wireshark-dev] A suggestion to improve navigating in large captures
Hi Richard, isn't this functionality already there? It's labeled as next mark and previous mark... On 20 February 2015 at 05:17, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, I often have to deal with large captures. They can be as large as several GB, and I often have to do things like filter on a specific type of packet, which will throw up a smallish number of packets of interest, but I need to look at the packets around those of interest. This involves selecting the first one of interest, eliminating the filter, inspecting, but if that is not the area of interest, I re-filter, then select the second packet of interest and go through the whole process until I find the group of packets that I am interested in. Now, I noticed that in the Edit menu we can mark all displayed packets. Then if the Go menu was enhanced with a Go To Next Marked the workflow I mentioned would be much easier. We could filter and if the packets are exactly what we are interested in, we could Mark all displayed, then select the first, clear the filter and then Go To Next Marked until we reach the group we are interested in. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Pozdrawiam / Best regards Michał Orynicz, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Orynicz location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] A suggestion to improve navigating in large captures
On Fri, Feb 20, 2015 at 12:40 AM, Michal Orynicz michal.oryn...@tieto.com wrote: Hi Richard, isn't this functionality already there? It's labeled as next mark and previous mark... You are correct. It is just not where I would have expected it, so perhaps our menu system is counter intuitive. I would have expected it under the Go menu, but it is under the Edit menu (and I did not notice that they were grayed out when I looked under the Edit menu, perhaps because I was not expecting them there.) On 20 February 2015 at 05:17, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, I often have to deal with large captures. They can be as large as several GB, and I often have to do things like filter on a specific type of packet, which will throw up a smallish number of packets of interest, but I need to look at the packets around those of interest. This involves selecting the first one of interest, eliminating the filter, inspecting, but if that is not the area of interest, I re-filter, then select the second packet of interest and go through the whole process until I find the group of packets that I am interested in. Now, I noticed that in the Edit menu we can mark all displayed packets. Then if the Go menu was enhanced with a Go To Next Marked the workflow I mentioned would be much easier. We could filter and if the packets are exactly what we are interested in, we could Mark all displayed, then select the first, clear the filter and then Go To Next Marked until we reach the group we are interested in. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Pozdrawiam / Best regards Michał Orynicz, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Orynicz location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Lua dissector Protocol Hierarchy
Hi, We have odd traffic on the network and we want to see specific names for them. I have a couple of generic protocol dissectors (for TCP and UDP in Lua); they allow me to see the protocol. [Description: cid:image004.png@01D04D1D.DC83CD40] The Statistic / Protocol Hierarchy tree shows Text item but I would like to see the name I picked. [Description: cid:image006.png@01D04D1D.DC83CD40] How can I do this? I have been searching with Google for hours and cannot find what I want (I may not be using the correct search terms). Thank you. -- Claude Marinier ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Use of tcp_dissect_pdus() with a protocol which has a variable length PDU length field
Hi,
While looking at improving the Websocket dissector, I found the need to
support variable length fields in tcp_dissect_pdus. Here is Bills
original mail (which had no replies).
On Fri, May 09, 2014 at 11:02:45AM -0400, Bill Meier wrote:
To: TCP re-assembly experts:
The MQTT protocol dissected by packet-mqtt.c runs over TCP. The field which
specifies the MQTT PDU length can be 1 to 4 bytes; the length of a complete
MQTT PDU can be less than 4 bytes.
So: trying use tcp_dissect_pdus() won't work since the fixed length
needed to handle the maximum size of the PDU length field is larger than
the possible minimum PDU size.
One approach is to assume that the complete length field will, with high
probability, always be in 1 TCP segment and thus available even if
specifying a 'fixed length' which includes only a 1 byte PDU length field.
(This is certainly not guaranteed).
Or, obviously, the dissector could do reassembly as described in
README.dissector section 2.7.2 Modifying the pinfo struct.
However, digging a little deeper, I note that tcp_dissect_pdus() is doing
something related to want_pdu_tracking (which I've never delved into and
which is not mentioned in README.dissector).
So it occurred to me that using a modified tcp_dissect_pdus() which allows
the get_pdu_len function to return DESEGMENT_ONE_MORE_SEGMENT might be a
workable approach.
So: I added the following to tcp_dissect_pdus() and modified
the packet-mqtt.c get_pdu_len() function appropriately.
(added code in tcp_dissect_pdus):
plen = (*get_pdu_len)(pinfo, tvb, offset);
+
+/* Is more data being requested before the PDU length can be
determined ?
+ * If so, request same.
+ */
+if (plen == DESEGMENT_ONE_MORE_SEGMENT) {
+if (!proto_desegment || !pinfo-can_desegment) {
+REPORT_DISSECTOR_BUG(DESEGMENT_ONE_MORE_SEGMENT not
allowed);
+}
+pinfo-desegment_offset = offset;
+pinfo-desegment_len = DESEGMENT_ONE_MORE_SEGMENT;
+return;
+}
+
if (plen fixed_len) {
My questions:
1. Is this a reasonable approach (it works AOK in my tests) ?
This approach looks fine to me. I have taken the same approach (but
replacing REPORT_DISSECTOR_BUG by DISSECTOR_ASSERT in
https://code.wireshark.org/review/7279
2. If not, and packet-mqtt should do reassembly itself, does the reassembly
code also need to do the want_pdu_tracking stuff ?
Bill
Looking at the current implementation of tcp_dissect_pdus, it is not
necessary to change want_pdu_tracking as the size of the new PDU is not
yet known.
Since this is an interesting API update, I thought that informing the
list would be a good idea.
Kind regards,
Peter
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
