Wireshark mailing list archives
Re: tshark option for reassembled fragment output
From: Evan Huus <eapache () gmail com>
Date: Sun, 3 Mar 2013 22:00:53 -0500
This is getting complicated. A few points in no particular order: === tshark default behaviour === We can't make -2 the default for tshark doing live capture, as that would require us to buffer all output until the capture is finished, which isn't very helpful. We might want to make it default when reading from a file, but then the two cases will behave subtly differently and there's a possibility for people to become confused. In general, there is *no way* for tshark doing a live capture to console to fill in things like fragment reassembly and request/response tracking the way wireshark does, because that would require it to predict the future (patches welcome!). So we already have a case where tshark *cannot* behave like wireshark, which is fundamentally very annoying. This raises the question of where we want our consistency - do we want tshark internally consistent by default (in which case we should keep -2 as an option) or do we want tshark to be as-consistent-as-possible with wireshark, even if we can't quite achieve all cases (in which case -2 should be the default except when doing a live capture). === architecture === I don't see an obvious good reason for tshark and wireshark to share any more of their processing code than they already do. Wireshark gets its two-pass behaviour 'for free' because it does one pass when displaying and one pass when saving. Tshark generally only does either one or the other in the first place (display or save), and even if it were to do both, it makes more sense for it to do them together than in series. Tangentially: Hadriel, you are correct with respect to the frame list (I worked on this yesterday in r48030) - I can't speak as much for the packet list store. === filtering === I *really* do not like the renumbering of frames that the read filters currently do (-R in wireshark, -2R in tshark). I find it confusing and not useful entirely apart from the fact that there is no graceful way for it to handle reassembly dependencies (see my "frame 1 depends on frames 1 and 1" example earlier). Does anybody know why it was added in the first place? It seems to me that it adds very little that was not already available by using a regular display filter and saving the results to a new file. === proposal === - Scrap "-R" and read filters entirely, making the requisite changes to the GUI so that the file->open filter behaves as Hadriel suggested (basically just a proxy for the regular display filter field). - Synchronize on -f for libpcap filters and -d for wireshark filters - Tshark only does one pass by default in all cases (so it's internally consistent). Keep -2 for two-pass analysis, but *never* renumber frames. - Improve the man page description for -2 to explain more clearly the benefits and drawbacks. Mention -2 early in the 'description' portion of the man page so that people looking for that functionality will find it. ___________________________________________________________________________ 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-request () wireshark org?subject=unsubscribe
Current thread:
- Re: tshark option for reassembled fragment output, (continued)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 03)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 03)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 03)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 03)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 03)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 04)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 02)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 03)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 03)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 03)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 03)
- Re: tshark option for reassembled fragment output Christopher Maynard (Mar 03)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 03)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 04)
- Re: tshark option for reassembled fragment output Jeff Morriss (Mar 08)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 08)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 09)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)
- Re: tshark option for reassembled fragment output Evan Huus (Mar 27)
- Re: tshark option for reassembled fragment output Hadriel Kaplan (Mar 27)