On Mar 3, 2013, at 10:00 PM, Evan Huus <eapache@xxxxxxxxx>
wrote:
> 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.
Sorry I should have been clearer... I wasn't talking about live capture.
The current -R isn't supported for live capturing when writing to a file, unless bug 2234 changes that. When you're NOT writing to a file but just stdout, there's no real benefit for detecting fragment future-dependency, because you're not going to print out the fragments anyway. There also isn't a benefit to request/response tracking - except for an extreme case of doing a '-R "dns.response_in > 1"' type thing.
So basically we could make it the new default whenever a '-R' is used and either '-r', or '-w', or both are used; but have it do the current one-pass when neither are used, or when '-1' is set. Clear as mud? :)
> === 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.
Oh it was more of wishful thinking than anything - it's too much work and prone to cause many new bugs to change it now anyway, and it'd be less efficient as you say. But looking at tshark.c:process_packet_first_pass() it's a lot like file.c:read_packet(), and process_packet_second_pass() shares a lot of code with cf_export_specified_packets() or cf_save_packets(). Or heck tshark.c:load_cap_file() shares a lot with file.c:cf_read(), and they both have their own versions of cf_open(), etc., etc. Obviously there are some differences around the GUI aspects, but in some alternate universe there's a file_handling.c that does all this stuff with the same code and uses callbacks for GUI differences, or is written in C++ and uses virtual classes/methods for those GUI differences. That way this fragment bug, and the time delta bug 8160, and the close file handle bug 3172, etc., are either bugs in both tshark and wireshark or bugs in neither, fixed at the same time, etc. And one could get wireshark-specific features, like specify ranges of packets to export, by only adding the command option to do so.
-hadriel