ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 9607] TFShark (Terminal FileShark)

Date: Thu, 15 May 2014 00:15:13 +0000

Comment # 36 on bug 9607 from
I think my biggest hangup is I don't like the file always being displayed in a
single row in the "packet view" and always having to be displayed as a "tree
view" in the "packet details" and never get a "list view".  I think "record
based files" should have the opportunity (but not a requirement) to have each
"record" in a row (see my comment #24).  Epan is extremely record based, so I
don't see how else I can get a listview without filetap/records.

I don't understand the "tvb guts" enough yet and to me it was like starting in
the middle.  I don't disagree with the option of treating the file like one
giant tvb, but it's going to take me a few iterations of code to get there. 
And I didn't want to do those steps in isolation in case I was missing obvious
architectural issues.  

Unless you think filetap is completely useless (or harmful), I didn't see any
wrong with the wiretap refactoring (and it was just going to be a small step 1
towards the goal of file support).  To me the next step after (getting) the
refactoring (to build on all platforms) would be either
1. Create a "simple filetap" that reads an entire file and presents it as a
tvb.  I think I understand the current layers enough to write that code. 
Others can then take that code to start adding file dissection.
2. Create a "filetap" that treats ELF files as "records".  I was personally
more interested in trying to architect this, understanding the goal is trying
to minimize code duplication in the definition of a "record".

But I don't see anything wrong with having both #1 and #2 in the code.


You are receiving this mail because:
  • You are watching all bug changes.