Wireshark-bugs: [Wireshark-bugs] [Bug 3096] Ability to annotate packet captures
Date: Mon, 13 Feb 2012 01:12:34 -0800 (PST)
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.
- Prev by Date: [Wireshark-bugs] [Bug 6836] IEEE1588 PTPv2 over IPv6
- Next by Date: [Wireshark-bugs] [Bug 6837] New: BSSGP Message not decoding properly
- Previous by thread: [Wireshark-bugs] [Bug 3096] Ability to annotate packet captures
- Next by thread: [Wireshark-bugs] [Bug 3096] Ability to annotate packet captures
- Index(es):