We can simply block waiting for input from the child process because we are
in a CLI that does not need to worry about updating a GUI while we're waiting
for packets and so forth.
Before I realized that I wrote a working (for me) method using select() that
I've left in for now (#ifdef'd out).
svn path=/trunk/; revision=22999
- Draw an empty graph if no items in given tick interval.
- Initialize interval_delta so we don't get overlaping x-scale labels.
- Some whitespace cleanup.
svn path=/trunk/; revision=22992
by tshark as well as Wireshark to fix compilation on Unix platforms.
This is due to the introduction of capture_sync.c (which calls
sync_pipe_errmsg_to_parent) to tshark_SOURCES in SVN revision 22969.
svn path=/trunk/; revision=22981
http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Macros.html#id2571572
G_INLINE_FUNC
#define G_INLINE_FUNC
This macro is used to export function prototypes so they can be linked with an external version when no inlining is performed. The file which implements the functions should define G_IMPLEMENTS_INLINES before including the headers which contain G_INLINE_FUNC declarations. Since inlining is very compiler-dependent using these macros correctly is very difficult. Their use is strongly discouraged.
This macro is often mistaken for a replacement for the inline keyword; inline is already declared in a portable manner in the glib headers and can be used normally.
svn path=/trunk/; revision=22980
To quote doc/README.developer:
Don't use "inline"; not all compilers support it. If you want to have a
function be an inline function if the compiler supports it, use
G_INLINE_FUNC, which is declared by <glib.h>.
svn path=/trunk/; revision=22979
case N ... M:
as that's not supported by all compilers.
Say so in the Portability section of README.developer, in the hopes of
discouraging others from using that GCCism.
svn path=/trunk/; revision=22976
rewrite the tshark capture code almost completely, to use dumpcap instead of it's own pcap functionality.
This works on Win32 and should work on unix/linux (but I'm not sure here). Some stuff needs to be cleaned up, some more may need to be rewritten to specifically work with unix/win32. Futher work needs to be done at:
1. read filters (simply document current behaviour?)
2. event loop polling
3. privileges
4. code cleanup (e.g. in capture_loop.c)
Be prepared that tshark might not work as before / expected at least in the next days!
svn path=/trunk/; revision=22969
tcp.time_relative ==> the time that has elapsed since the
first packet that was seen in the current TCP stream
tcp.time_delta ==> the time that has elapsed since the
last packet that was seen in the current TCP stream
Calculating these timestamps is turned off by default to not
use the extra memory that is needed for the per-packet-data.
It can be turned on through the TCP protocol preferences
svn path=/trunk/; revision=22966
This is an update for the DCCP dissector and has previously been sent to
the DCCP dissector maintainer, Francesco Fondelli, who supplied
the Acked-by. I have been using it with profit for several weeks.
This patch provides the following extensions:
* type-dependent decoding of feature-negotiation options (NN and SP types of
options, NN is a 1..6 byte value in network-byte-order, SP is always a list of
unsigned char)
* decoding for CCID3 Send Loss Event Rate feature
* some pretty-printing of options
* decoding of CCID3-specific options
- Loss Event Rate (receiver report)
- Receive Rate (also reported by receiver)
* there was a change in the spec - the NDP count at sometime `grew' from 3 to
6 bytes (it was the same in the kernel). I have updated the data type from uint32 to
uint64
* utility function to decode from network-byte-order into host byte order with
variable length
svn path=/trunk/; revision=22961
a protocol depends on.
- Make sure we need to add asn files to only 1 Makefile instead
of 3 (Makefile, Makefile.nmake, ../Makefile.am)
- Change the Makefiles of the camel protocol to use the new structure.
svn path=/trunk/; revision=22950
