Age | Commit message (Collapse) | Author | Files | Lines |
|
protocols ...
svn path=/trunk/; revision=9538
|
|
byte past the end of the tvbuff.
svn path=/trunk/; revision=9445
|
|
0 - now that "tvb_ensure_length_remaining()" ensures that there's at
least one byte of data, we should use "tvb_length_remaining()" for
FT_PROTOCOL fields.
svn path=/trunk/; revision=9440
|
|
to tethereal. It could be added to Ethereal, but the GUI changes to
allow the user to select PDML as a print format have not been added.
Provide a python module (EtherealXML.py) to help parse PDML.
Provide a sample app (msnchat) which uses tethereal and EtherealXML.py
to reconstruct MSN Chat sessions from packet capture files. It produces
a nice HTML report of the chat sessions.
Document tethereal's PDML and EtherealXML.py usage in doc/README.xml-output
Update tethereal's manpage to reflect the new [-T pdml|ps|text] option
svn path=/trunk/; revision=9180
|
|
our new scheme.
svn path=/trunk/; revision=9172
|
|
pointers to the first *and* last child, in the "proto_node" structure
itself. That saves us one level of indirection and memory allocation,
and lets us append to a tree by appending to the last child directly,
rather than having to scan through the list of siblings of the first
child to find the end of that list.
svn path=/trunk/; revision=9171
|
|
replace tvb_raw_offset() which is essentially a simple assignment and which
is called a lot with a macro.
this makes my tethereal testcase 2-3% faster.
svn path=/trunk/; revision=9152
|
|
one member - or have one that's not used, so get rid of those unions.
svn path=/trunk/; revision=9151
|
|
when adding them to the free list, cast the pointer to the structure to
a pointer to a "freed_item_t" which contains the "next" pointer.
This reduces the memory requirement for some of those structures, and
leaves us free to slab-allocate structures that have a "next" pointer
for other reasons.
svn path=/trunk/; revision=9150
|
|
structure, rather than separately allocating "fvalue_t"s and having the
"field_info" structure point to them - this appears to speed up protocol
tree construction a bit.
svn path=/trunk/; revision=9146
|
|
so that we can change tvb_get_ds_tvb() into a macro.
This function was a single line assignment and was called a lot.
This made tethereal ~2.5% faster in one testcase I use.
svn path=/trunk/; revision=9141
|
|
svn path=/trunk/; revision=9140
|
|
svn path=/trunk/; revision=9139
|
|
create generic macros for allocating/freeing structures.
remove one more slow GMemChunk and replace it with a simple linked list
~4% speed improvement in my tests.
the allocated data is never freed. this may be a problem if ethereal is
ever supported on a platform lacking resource tracking but makes the
implementation faster and simpler.
svn path=/trunk/; revision=9095
|
|
items aren't individually g_mallocated and can't be g_freed, only the
chunks can.
svn path=/trunk/; revision=9091
|
|
other place in the code and this reduces one unnecessary function call overhead.
and it makes ethereal ~1% faster.
svn path=/trunk/; revision=9088
|
|
svn path=/trunk/; revision=9087
|
|
svn path=/trunk/; revision=9086
|
|
svn path=/trunk/; revision=9085
|
|
a function
svn path=/trunk/; revision=9084
|
|
This function is also very small, so small that teh overhead for the actual function call and return is likely to be a significant part
of its execution time.
change it into a macro and make it thus slightly faster by eliminating the function call overhead.
svn path=/trunk/; revision=9083
|
|
svn path=/trunk/; revision=9075
|
|
Removed the GMemChunk used to allocate/free field_info structures
and used a free list to store the freed structs until they are allocated again.
Ethereal will allocate more field_info structs as it needs to but never free them. Instead the are just placed in a cheap and fast free list so that if we
want to use the struct again, this will be fast.
This affects the speed of the two functions
alloc_field_info() that should be slightly faster now
free_field_info() that was replaced with a 2 line macro.
All in all my testing suggests that ethereal is 2-3% faster with this patch.
svn path=/trunk/; revision=9073
|
|
and make it even faster
svn path=/trunk/; revision=9064
|
|
In the GPROF logs proto_registrar_get_nth() used to take anything between 2.5 and 5.5% of the time.
Replace the GLIB array with a handroleld one for one of the private structures.
the function should now be virtually zero cost
and thus ethereal should be 2.5-5.5% faster on those traces.
anyone that wants to, please rerun GPROF with this fix and see what has changed.
svn path=/trunk/; revision=9058
|
|
memory if it throws an exception, as it checks whether the entire string
is in the tvbuff *before* allocating a buffer for it, and that also
means that if the length is absurdly large, an exception will be thrown,
rather than the memory allocation failing.
svn path=/trunk/; revision=9043
|
|
Make "proto_is_protocol_enabled()" and "proto_get_protocol_short_name()"
take a "protocol_t *" as an argument, so they don't have to look up the
"protocol_t" - this will probably speed them up considerably, and
they're called on almost every dissector handoff.
Get rid of a number of "proto_is_protocol_enabled()" calls that aren't
necessary (dissectors called through handles, including those called
through dissector tables, or called as heuristic dissectors, aren't even
called if their protocol isn't enabled).
Change some direct dissector calls to go through handles.
svn path=/trunk/; revision=8979
|
|
Fix the names that contained other characters.
svn path=/trunk/; revision=8959
|
|
any previously-allocated version first, so that they don't leak memory.
From Olivier Biot: add a "proto_item_append_string()" routine, to append
to the string value a protocol tree item has.
svn path=/trunk/; revision=8821
|
|
that probably means you've registered two fields with the same field ID
variable, which is an error.
Fix the bugs doing so found.
svn path=/trunk/; revision=8629
|
|
support for registering fields after all the protocol
registration routines are called (i.e., adding fields to the
named field tree as they're registered);
fix the GTK 2.x version of the field list dialog to show the
correct name.
svn path=/trunk/; revision=8248
|
|
generating display filters from FT_IPv4 fields.
svn path=/trunk/; revision=8110
|
|
use them when generating display filters to match field values. Use
"%{FLT_DIG}g" rather than "%{FLT_DIG}f" for FT_FLOAT.
svn path=/trunk/; revision=8109
|
|
methods, and use them when constructing display filters.
svn path=/trunk/; revision=8107
|
|
have plugin support. (Don't do so if we *do* have it, because if
"proto_init()" ever changes so that it doesn't use the argument even if
we have plugin support, we want a warning so we know that we should get
rid of that argument.)
svn path=/trunk/; revision=7972
|
|
for FT_FLOAT and FT_DOUBLE values.
svn path=/trunk/; revision=7962
|
|
tvb_get_string() - takes a tvbuff, an offset, and a length as
arguments, allocates a buffer big enough to hold a string with
the specified number of bytes plus an added null terminator
(i.e., length+1), copies the specified number of bytes from the
tvbuff, at the specified offset, to that buffer and puts in a
null terminator, and returns a pointer to that buffer (or throws
an exception before allocating the buffer if that many bytes
aren't available in the tvbuff);
tvb_get_stringz() - takes a tvbuff, an offset, and a pointer to
a "gint" as arguments, gets the size of the null-terminated
string starting at the specified offset in the tvbuff (throwing
an exception if the null terminator isn't found), allocates a
buffer big enough to hold that string, copies the string to that
buffer, and returns a pointer to that buffer and stores the
length of the string (including the terminating null) in the
variable pointed to by the "gint" pointer.
Replace many pieces of code allocating a buffer and copying a string
with calls to "tvb_get_string()" (for one thing, "tvb_get_string()"
doesn't require you to remember that the argument to
"tvb_get_nstringz0()" is the size of the buffer into which you're
copying the string, which might be the length of the string to be copied
*plus 1*).
Don't use fixed-length buffers for null-terminated strings (even if the
code that generates those packets has a #define to limit the length of
the string). Use "tvb_get_stringz()", instead.
In some cases where a value is fetched but is only used to pass an
argument to a "proto_tree_add_XXX" routine, use "proto_tree_add_item()"
instead.
svn path=/trunk/; revision=7859
|
|
svn path=/trunk/; revision=7850
|
|
to provide that method.
svn path=/trunk/; revision=7849
|
|
svn path=/trunk/; revision=7832
|
|
svn path=/trunk/; revision=7792
|
|
value, just copy the specified number of bytes and stick a '\0' at the
end, don't use "tvb_get_nstringz0()" - yes, you end up copying more
bytes, but you don't have to bother looking for a '\0' that might not
even be present (if the string is null-padded rather than
null-terminated).
Also, set the length of the item to the specified length, rather than to
the length up to the terminating '\0' - if the string is null-padded,
the field should include all the padding bytes.
svn path=/trunk/; revision=7785
|
|
length (rather than being given -1), the length is, in most cases, the
maximum length of a null-*padded* string, rather than the actual length
of a null-*terminated* string. Treat it as such - allocate a buffer one
larger than the length (to leave room for a terminating '\0'), and pass
the size of that buffer to "tvb_get_nstringz0()". (Otherwise, in those
cases, the last character of the string is chopped off.)
Allow "proto_tree_add_string()" to add FT_STRINGZ items to the protocol
tree, as well as FT_STRING items.
In "alloc_field_info()", if we're passed a length of -1 and the field is
an FT_STRINGZ, don't make the length be the length remaining in the
tvbuff; that way, you *can* use a length of -1 in
"proto_tree_add_item()" for an FT_STRINGZ item, and have it get the
actual length by looking for the terminating '\0'.
(We might want to distinguish between null-terminated and null-padded
strings, e.g. with an FT_STRINGZPAD type. Null-terminated strings
rarely, if ever, have a specified length; the length is found by
scanning for the terminating '\0'. Null-padded strings presumably
always have a specified length, which is the length to which the string
is padded.)
svn path=/trunk/; revision=7784
|
|
Things can happen if we pass a zero buffer length to tvb_get_nstringz0().
Throw an exception if this happens.
In various dissectors make sure the tvb_get_nstringz0()'s buffer length
is greater than zero.
svn path=/trunk/; revision=7688
|
|
ftypes, and how to add them to more types and use them in more places.
svn path=/trunk/; revision=7636
|
|
"proto_construct_dfilter_string()", to more accurately reflect what it
does.
Give it, and "proto_can_match_selected()", an "epan_dissect_t *"
argument, which replaces the raw data pointer argument to
"proto_construct_dfilter_string()".
For fields that don't have a type we can directly filter on, we don't
support filtering on the field as raw data if:
the "epan_dissect_t *" argument is null;
the data source tvbuff for the field isn't the tvbuff for the
"epan_dissect_t" in question (i.e., it's in the result of a
reassembly, and "frame[N:M]" can't get at it).
Trim the length the raw data in the case of such a field to the length
of the tvbuff for the "epan_dissect_t" in question, so we don't go past
it. Fetch the raw data bytes to match from that tvbuff.
Have "proto_construct_dfilter_string()" return a null pointer if it
can't construct the filter string, and have "protocolinfo_packet()" in
the tap-protocolinfo tap ignore a field if
"proto_construct_dfilter_string()" can't construct a filter string for
it - and have it pass NULL as the "epan_dissect_t *", for now. If
somebody decides it makes sense to dump out a "frame[N:M] =" value for
non-registered fields, it can be changed to pass "edt".
svn path=/trunk/; revision=7635
|
|
given a tvbuff/offset pair referring to the byte past the end of the
item. Use it in one place in the SMB dissector (there are plenty of
other places where it could be used as well).
svn path=/trunk/; revision=7603
|
|
of their value. Provide such a method for FT_BYTES, FT_UINT_BYTES,
and FT_ETHER. Have proto_alloc_dfilter_string() use the new methods.
This is part of a movement of ftype-related code out of proto.c and
into the ftype code. The immediate effect is that generated display
filters for long byte sequences don't incorrectly have trailing periods
("...") to indicate continuation.
svn path=/trunk/; revision=7100
|
|
to be using it for stuff that should be hex, and for stuff that should
be Boolean. Use BASE_DEC if it should be decimal, BASE_HEX if it should
be hex, and make it Boolean if it should be Boolean.
svn path=/trunk/; revision=7053
|
|
svn path=/trunk/; revision=6956
|