Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3096] Ability to annotate packet captures

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3096

--- Comment #39 from Michael Tüxen <tuexen@xxxxxxxxxxxxx> 2012-02-13 01:12:33 PST ---
(In reply to comment #38)
> (In reply to comment #37)
> > Given that pcap-NG supports multiple comments per packet, Microsoft Network
> > Monitor file format supports it as far as I can tell, and Network Instruments
> > Observer format also looks as if it can support it, we should support it as
> > well.
> > So we should support adding comments to the set of comments, deleting comments
> > from the set of comments, and editing comments in the set of comments.
> 
> Hmm, that complicates things a bit. What should our frame work look like?
> Should pcapng.c just extract the comment block into a buffer and return it
> in the struct wtap_pkthdr? If done that way we might be able to preserve
> options we don't handle if re-saving the file.
We could replace the pointer to a string to a pointer to a list of strings...
So when reading a comment we would append it to the list...
> 
> Would it be OK to join multiple comments into one when doing editing, and write
> it back as one option? I'm not sure what the GUI would look like to edit
> multiple comments - a notebook with one tab per comment option?
> 
> Is multiple comment options desirable? If not update the spec to just allow one
> occurance?
>From my perspective:
A single comment which allows me to use UTF-8 characters is enough I'll ever
need.
What I can imagine: People wanting to use RTF features like boldface, italic,
large fonts,
select font. I wouldn't be shocked if people would file a bug report that they
can't
attach a Powerpoint presentation or Word document to a packet as a comment...
I do see one limitation: The length of a single comment is currently limited to
64KB.

My suggestion would be: Implement something useful as simple as possible first.
Get feedback and decided how to expand the functionality.

For me it would be really useful to be able to load/display/edit/save single
UTF-8 comments
in pcapng files.
> 
> 
> > Pcap-NG comments are UTF-8, as per the spec.  NetMon comments are separated
> > into a UTF-16 title and an RTF(!) body; presumably it uses the newer versions
> > of RTF with Unicode support.  I'm not sure whether Observer supports Unicode
> > comments (if so, it's presumably UTF-8, as the comments I've seen in Observer
> > files are ASCII rather than UCS-2 or UTF-16).  For the latter, we should
> > probably start by converting the title to UTF-8, turning the RTF into UTF-8
> > plain text, and prepending the title if it's not empty.
> 
> > As for indicating whether a frame has a comment, NetMon puts a "#" after the
> > frame number in the frame number column; having a separate column to indicate
> > whether a frame has a comment might be a good idea (and having a way of
> > indicating, in the packet list, whether a frame has any expert info items, and
> > what severity the highest-severity item has, might be also useful).  
> 
> Use the flags struct in frame_data? We might want a (global) flag to indicate
> that comments have been edited.
Yes. We need to ask the user if he wants to save the changes when he closes the
tracefile/application.
> 
> >Having a
> > column to contain the comment itself, however, probably wouldn't work well
> > except for the shortest of comments.  In examples I've seen in the NetMon blog
> > and the Observer manual, the comment is multiple lines and rather long (in the
> > NetMon blog - see the URL in an earlier comment of mine - the comment includes
> > a significant chunk of Microsoft MSDN documentation).
> 
> +1
> 
> > (As for
> >     BTW is all 5 nstime_t structs needed, couldn't the "others" be computed
> > from the first one using a smaller member containing "offset"
> > the answer is "yes".)
> 
> No shortage of stuff to do :-)

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.