[Wireshark-dev] Should dissect_tcp_pdus be used as much as possible?
Hi, Should reassembly be enabled in as many TCP protocols as possible? That is, is it desirable that TCP-based protocols use dissect_tcp_pdus with reassembly set to true? I am asking because I was fixing an error in the return value of the Plan 9 dissector[1]. While at it, I converted it to use dissect_tcp_pdus as that was trivial. I have not seen a fragmented 9p capture though. Kind regards, Peter https://lekensteyn.nl [1]: https://code.wireshark.org/review/2836/ ___ 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] Initial RTT
2014-07-03 12:45 GMT+02:00 Jasper Bongertz jas...@packet-foo.com: 2014-07-02 20:59 GMT+02:00 Jasper Bongertz jas...@packet-foo.com: Hello, as promised during Sharkfest, I checked the latest developer builds for the accuracy of the calculation of initial RTT for TCP connections. So far I have only seen correct results, even in cases with heavy packet loss during the three way handshake. So I think the code is good. I also checked traces where the TCP expert was incorrectly assuming a retransmission when it was in fact an out-of-order packet. Those are now correctly identified, at least when we have the handshake and thus initial RTT. Thumbs up for that. Regarding the way to handle missing handshakes - I would go with the old 3ms arbitrary value in that case, because most Wireshark captures are taken in local network environments. Higher values are problematic because retransmissions are not flagged anymore and called out-of-order instead, which could lead to a lot of confusion out there. I prefer false positives for retransmissions over out-of-orders. Again, thanks for the effort! Cheers, Jasper Hi, if it is working great (Evan changed the timer back to its old 3ms arbitrary value in case we do not have the handshake) would it make sense to backport this change from the development branch to the 1.12 one (before Wireshark 1.12 gets released)? Regards, Pascal. yes, it would definitely be nice to have it in 1.12 if possible. Cheers, Jasper Hi Jasper, it was just merged. Cheers, Pascal. ___ 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] Should dissect_tcp_pdus be used as much as possible?
Yes I think tcp_dissect_pdus should be used as much as possible. I even made a list (at least a few months ago) of potential dissectors that could be converted: packet-banana.c packet-beep.c - maybe packet-bzr.c packet-cigi.c packet-classicstun.c packet-distcc.c packet-dtn.c packet-dtpt.c packet-elcom.c packet-fcip.c packet-gdsdb.c packet-hartip.c packet-ipsi-ctl.c packet-kingfisher.c - maybe packet-ldp.c packet-llrp.c packet-mikey.c packet-ms-mms.c packet-msdp.c packet-ntp.c packet-omapi.c - maybe (but probably not) packet-pptp.c packet-rsip.c packet-rtsp.c - maybe packet-tds.c packet-tpkt.c packet-vicp.c packet-vnc.c packet-x11.c packet-zebra.c There may be more and some of these may have already been converted (although I doubt it), but I figured it was a good starting point. You're welcome to work on any of them. It was a project I thought about doing, but never got started. Michael -Original Message- From: Peter Wu pe...@lekensteyn.nl To: wireshark-dev wireshark-dev@wireshark.org Sent: Fri, Jul 4, 2014 4:39 am Subject: [Wireshark-dev] Should dissect_tcp_pdus be used as much as possible? Hi, Should reassembly be enabled in as many TCP protocols as possible? That is, is it desirable that TCP-based protocols use dissect_tcp_pdus with reassembly set to true? I am asking because I was fixing an error in the return value of the Plan 9 dissector[1]. While at it, I converted it to use dissect_tcp_pdus as that was trivial. I have not seen a fragmented 9p capture though. Kind regards, Peter https://lekensteyn.nl [1]: https://code.wireshark.org/review/2836/ ___ 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 ___ 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] Should dissect_tcp_pdus be used as much as possible?
On Jul 4, 2014, at 1:36 AM, Peter Wu pe...@lekensteyn.nl wrote: Should reassembly be enabled in as many TCP protocols as possible? Yes. That is, is it desirable that TCP-based protocols use dissect_tcp_pdus with reassembly set to true? That is a different question. TCP-based protocols *where the data stream is broken up into PDUs, and the size of a PDU is always = N, for some value of N 0, and where the length of the PDU can always be calculated from the contents of the first N bytes of the protocol*, should use tcp_dissect_pdus with the reassembly parameter either hardwired to TRUE or passed as a user-configurable parameter that defaults to TRUE. (That could be simplified to should TCP-based protocols use tcp_dissect_pdus, *if possible*, with a default setting of do reassembly?, to which the answer is yes.) However, not all TCP-based protocols are like that; HTTP, for example, isn't, and it uses different helper routines (see epan/req_resp_hdrs.[ch]). ___ 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] Should dissect_tcp_pdus be used as much as possible?
The list I provided (http://www.wireshark.org/lists/wireshark-dev/201407/msg00018.html) follows the criteria mentioned by Guy. The maybes are where it appeared at first/quick glance that the contents can be calculated within the first N bytes, but there was too much logic/code to follow to guarantee that. -Original Message- From: Guy Harris g...@alum.mit.edu To: Developer support list for Wireshark wireshark-dev@wireshark.org Sent: Fri, Jul 4, 2014 1:32 pm Subject: Re: [Wireshark-dev] Should dissect_tcp_pdus be used as much as possible? On Jul 4, 2014, at 1:36 AM, Peter Wu pe...@lekensteyn.nl wrote: Should reassembly be enabled in as many TCP protocols as possible? Yes. That is, is it desirable that TCP-based protocols use dissect_tcp_pdus with reassembly set to true? That is a different question. TCP-based protocols *where the data stream is broken up into PDUs, and the size of a PDU is always = N, for some value of N 0, and where the length of the PDU can always be calculated from the contents of the first N bytes of the protocol*, should use tcp_dissect_pdus with the reassembly parameter either hardwired to TRUE or passed as a user-configurable parameter that defaults to TRUE. (That could be simplified to should TCP-based protocols use tcp_dissect_pdus, *if possible*, with a default setting of do reassembly?, to which the answer is yes.) However, not all TCP-based protocols are like that; HTTP, for example, isn't, and it uses different helper routines (see epan/req_resp_hdrs.[ch]). ___ 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 ___ 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
