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 #38 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2012-02-13 00:41:06 PST ---
(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.

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?


> 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.

>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.