Bugs in the tshark '-z io,stat' output:
1: The LOAD stat in the last row of the output is inaccurate because rpc.time
is divided by the full interval rather than limiting it to the capture
duration.
2: An The empty comma field (for outputting total frames and bytes) is ignored
when it is the first field in the command.
3: Intervals at the end of capture that contain no data are not displayed. Such
intervals are as important to see as those (zero data intervals) that occur
earlier in the capture.
4: Floating point numbers are not properly aligned under their column headers.
Enhancements to '-z io,stat' output:
1. Column widths are determined by the maximum magnitude of their values rather
than set to a fixed width of 15 chars which allows for more stats to be
displayed per row without wrapping.
2. To improve readability, filters wrap at 102 chars or the table width,
whichever is greater, and wrap on the nearest space. An option can be added to
alter the 102-char limit.
3. Column numbers begin at 1 instead of 0.
4. The columns and entire output are enclosed in a border for improved
presentability in reports. The table can be imported into a spreadsheet by
specifying the vertical bar as the data delimiter.
"Fixed" compiling on Ubuntu
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6883
svn path=/trunk/; revision=41355
clickable to open an edit window.
- Add checks for NULL pointers.
Help with a different color LED possibly with Jeff's (c) in it apreceated.
Should the LED be placed elsewhere or the whole thing done differently?
svn path=/trunk/; revision=41242
tap-iostat.c: In function ‘iostat_draw’:
tap-iostat.c:542:5: error: implicit declaration of function ‘itoa’
tap-iostat.c:756:9: error: too few arguments for format
tap-iostat.c:756:9: error: too few arguments for format
itoa() could be converted into a g_snprintf(), but the buffer used is only
one character long. Is that right?
For the printf() format one, I'm not sure what was intended.
svn path=/trunk/; revision=41234
make Save-As/Displayed/All-Packets save not only the displayed packets but
also any other packets needed (e.g., for reassembly) to fully dissect the
displayed packets.
This works only for the "All packets" case; choosing only the Selected packet,
the Marked packets, or a range of packets would require actually storing which
packets depend on which (too much memory) or going through the packet list many
times (too slow). Also, this behavior is always the case: you can't save the
displayed packets without their dependencies (I don't see why this would be
desirable).
So far this is done for SCTP and things using the reassembly routines (TCP has
been tested).
The Win32 dialog was modified but hasn't been tested yet.
One confusing aspect of the UI is that the Displayed count in the Save-As
dialog does not match the number of displayed packets. (I tried renaming the
button "Displayed + Dependencies" but it looked too big.) The tooltip tries
to explain this and the fact that this works only in the All-Packets case;
suggestions for improvement are welcome.
Implementation details:
Dissectors (or the reassembly code) can list frames which were needed to
build the current frame's tree. If the current frame passes the display
filter then each listed frame is marked as "depended upon" (this takes up the
last free frame_data flag).
When performing a Save-As/Displayed/All-Packets then choose packets which
passed the dfilter _or_ are depended upon.
svn path=/trunk/; revision=41216
time stamps on all packets in a set, you can't determine the start and
end time of the packets in the set (even one timestampless packet throws
the determination off - was that packet before the first time-stamped or
after the last time-stamped packet, or between them?).
svn path=/trunk/; revision=41187
and r39501:
Setting _XOPEN_SOURCE to 600 is only allowed on Solaris 10 if the compiler is
set to C99 mode. Conversely (and as reported in the bug), simply defining it
(but with no value) is not allowed if the compiler *is* compiling to C99.
So, don't define _XOPEN_SOURCE at all on Solaris. Keep defining it as 600 on
other OS's as (also) requested in that bug.
Maybe there's a cleaner way to do this but all of this is a "trickery" mess
anyway...
svn path=/trunk/; revision=41182
new_packet_list: crash in add_byte_views from decrypted zigbee data
The cause of the crash I saw was that the add_byte_views() function in
main_proto_draw.c relies on output from previous dissector run while the
function may eventually trigger dissector to run again which wipes out the
previous output.
The patch copies the output of the dissector before calling add_byte_tab() so
that even when add_byte_tab() updates the dissector output, the loop continues
with previous dissector output.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5130
svn path=/trunk/; revision=41158
* Add support in the GUI for pipes.
* Allow the local interfaces to be rescanned via the GUI.
* Allow remote interfaces to be added and deleted.
The GUI can be extended to support other ways of capturing.
svn path=/trunk/; revision=41105
GENERATED_H_FILES.
If we have DIRTY_GENERATED_C_FILES, use it the same way we use
GENERATED_C_FILES.
GENERATED_FILES is "everything to nuke on a "make maintainer-clean"",
not "everything to put into the distribution".
svn path=/trunk/; revision=41075
Remove a bunch of stuff copied over from ui/gtk/Makefile.am that doesn't
apply here.
There's no DIRTY_GENERATED_C_FILES.
svn path=/trunk/; revision=41074
Anders Broman