File -> Export Packet Dissections
(for the "print to file", "export as CSV", "export as C array",
"export as PSML", and "export as PDML" items)
File-> Export Selected Packet Bytes
File -> Export SSL Session Keys
File -> Export Objects
(for exporting objects transferred over HTTP, DICOM, or SMB)
menu items.
The operations under Export really weren't that related - about all they
had in common was that they wrote to a file stuff other than packets
in a capture file format; the operations in the groups *under* Export
were related, so the groups are now menu items of their own.
This way, the File menu more immediately indicates what options of that
sort are available.
It also means that the Export Packet Dissections item might make it
clearer that what you get from that is *NOT* something that can just be
read back into Wireshark, as at least one user who asked "how do I get
my capture back from this?" on ask.wireshark.com thought. If that
doesn't suffice, perhaps renaming it to "Export Dissected Packets" would
help; if *that* doesn't suffice, perhaps Kevin Cullimore's suggestion
that it say "Report" rather than "Export" will do the trick:
From: Kevin Cullimore <kcullimo@runbox.com>
Subject: [Wireshark-users] Re: Should the "export as text" item be in an "Export Human-readable..." item in the File menu?
Date: May 19, 2012 8:31:23 PM PDT
To: wireshark-users <wireshark-users@wireshark.org>
Would classifying the asymmetric export (ones that lack a
corresponding "import" action) formats as "reports" help clear
up the original ambiguity/misunderstanding? It seems that most
of the gui-based network tools I'm forced to periodically
interact with rely upon that term with at least some success.
(Or perhaps some other verb would be right in some cases, e.g. "Save SSL
Session Keys".)
This also sets a pattern for another upcoming change - splitting "Save
As" into "Save As", which always saves every packet and makes the new
file the current file, and "{Verb} Specified Packets", which lets you
specify which packets to save and does *not* make the new file the
current file. That'd simplify the code a bit, and might clear up the
new only-in-the-trunk issue in bug 6640 - having "Save As" default to
saving displayed packets currently means that it acts more like the
latter of those functions.
svn path=/trunk/; revision=42778
so "Save" should, for non-temporary files, mean "save the current state
of the capture file on top of the existing file" without prompting for a
file name.
That means we have to do a "safe save" - i.e, write the capture out to a
new file and, if that succeeds, rename the new file on top of the old
file - as the actual packet data to write out is in the file we're
overwriting, not in memory. (We'd want to do that anyway, of
course....)
Update some comments.
Clean up indentation slightly, and get rid of an unnecessary variable
(in all the cases where we use it, we assign it the same value, and that
value isn't modified out from under us before we use it).
Note that after a "Save", or a "Save As" that writes out all captured
packets, we shouldn't have to close the current file and open the new
file and reread it - we should be able to open the new file and update
the frame offsets in the frame_data structures.
Note that we need to do some a better job of reporting rename failures.
svn path=/trunk/; revision=42777
on Windows, and that ws_stdio_rename() uses MoveFileEx() with
MOVEFILE_REPLACE_EXISTING and should therefore remove the target if it
exists, the extra "remove the target first" stuff should not be
necessary on Windows - if we remove it, it also keeps the code from
removing the target and then having the rename fail, with the result
that the target no longer exists.
svn path=/trunk/; revision=42776
(we require GLib 2.14 or later, and always use UTF-8 for pathnames on
Windows), to note that ws_stdio_rename() should have UN*X-style
rename semantics in that it removes the target if necessary, and to give
more details in other ways.
Clean up indetation a bit.
svn path=/trunk/; revision=42775
For such protocols, hte state gets out of sync of for example the same PDU is invoked twice in a row, which sometimes can happen if there is tcp retransmission and we see the same PDU twice. First for hte original segment and a second time for the tcp retransmission.
These protocols might lack an easy way to detect that a PDU is seen twice or out of order.
To handle this a little better, offer a TCP option that defaults to being disabled but when enabled skips invoking any subdissector for retransmitted or out of order packets.
(For some virtualization environments it sometimes becomes VERY common to see false tcp retransmissions due to segments being captured twice making this even worse)
We dont want this option to default to ON because for most cases we do want the current behaviour where the subdissector is called twice, or more, for any PDU that is retrasnmitted on the TPC layer.
For example, assume a SMB response packet is retransmitted on the TCP level.
This may result in a capture file that looks like
1 -> SMB request
2 <- SMB response to 1
... 1 second ...
3 <- SMB response to 1 TCP retransmission
For this case we definitely want packet 3 to be passed to the SMB layer so that
the request/respons ematching will detect that the response time for this transaction was > 1.0 second
We want smb.time to indicate the delta betwenn packets 1 and 3
as well as the SMB Service Response Time to indicate that this command took very long.
svn path=/trunk/; revision=42774
save, we post capture file callback events similar to the ones posted
when reading a capture - otherwise, the reload will leave the welcome
screen up.
Rename cf_cb_file_save_reload_finished to cf_cb_file_reload_finished,
add a cf_cb_file_reload_started callback, have them work similarly to
read_finished and read_started except that the reload uses "Reloading"
in the progress bar and status bar.
Clean up some indentation while we're at it.
svn path=/trunk/; revision=42764
Revert r42758 as it only helps in one case; rather, fix it correctly: if
we're redissecting or refiltering, clear any frame dependencies as we go
along. (Fortunately, frame dependencies are all forward dependencies--
meaning that a given frame can only be depended upon by a later frame--
so we can do this as we rescan the packets/frames.)
svn path=/trunk/; revision=42762
Clear the dependent_of_displayed flag when there's no dfilter. This only
helps the case when you clear a display filter before moving on to another
display filter.
svn path=/trunk/; revision=42758
(It seems to me that this issue would rarely, if ever, actually occur).
Also:
- Use val_to_str_const() as appropriate;
- Localize some variables;
- Remove unneeded initializers;
- Do some parenthesizing;
- Use a consistent formatting style;
- Do whitespace cleanup.
svn path=/trunk/; revision=42754
Don't mark frames as dependent upon a displayed frame unless the (supposedly)
displayed frame is actually displayed. (Fix to r41214 <sigh>.)
svn path=/trunk/; revision=42752
Also:
- #if 0 out some unused hf[] entries;
- use val_to_str_const() in a few places;
- remove some unneeded initializers;
- do col_set_str()/col_clear() before referencing tvb;
- reformat hf[] entries;
- Fix whitespace (4-space tabs, etc).
svn path=/trunk/; revision=42746
- use #if 0/#endif to comment out code(instead of /* ...*/
- remove unused #define
- replace col_clear()/col_add() by col_set()
svn path=/trunk/; revision=42745
g_unichar_isprint() is for *wide characters*.
For UTF-8 multibyte characters we could
use g_utf8_validate() and g_utf8_next_char(),
but IMHO format_text_* should be ASCII-only.
We rather need to store encoding of FT_STRING[Z]
and in proto_item_fill_label() call appropiate
function.
For ENC_ASCII use format_text(),
for unicode (ENC_UTF*, ENC_UCS*) use format_text_utf(),
etc..
svn path=/trunk/; revision=42727
"unsaved_changes", and have it be TRUE iff changes have been made to the
file since it was read - *not* if it's a temporary file from a live
capture.
Check the "is_tempfile" member, and the "unsaved_changes" member, when
appropriate.
Just have a set_toolbar_for_capture_file() routine that updates the
"save", "close", and "reload" toolbar as appropriate, given a
capture_file structure - absorb the function of
set_toolbar_for_unsaved_capture_file() into it.
svn path=/trunk/; revision=42721
