(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
column. Conversation spans (setup frame to last frame) are shown with a
square bracket. Linked frames are shown with a circle.
Use correct column justifications in Qt. Move common
justification-related packet list code to ui/packet_list_utils.[ch].
Add a last_frame element to conversation_t.
svn path=/trunk/; revision=50447
while caching the last element from the conversation hash chain lists speeds-up
the operation when the hash/chain lists are actually built, it
does NOT help a lot when a certain random conversation which is in the hash
table is looked-up.
I did some profiling and tracing and I saw that a lot of cpu time is spent in
the function conversation_lookup_hashtable() when wireshark
is asked to show the "Flow Graph", "TCP Conversations", "Voip Calls". I used
two types of captures with over 500k packets:
- tcp packets having the _same_ src ip addr, src tcp port, dst ip addr, dst tcp
port
- (mostly) sip packets containing sdp payloads which advertise the _same_ ip
addr, udp port for media
these types of captures lead to _huge_ chain lists behind the same hash bucket
(to which the conversation is actually mapped)
the solution would be to cache the last found conversation into the head of the
chain list and to use it whenever it is possible; most of the time the look-up
will be in O(1) instead of O(n) (n - number
of elements in the list).
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7149
svn path=/trunk/; revision=42141
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4422
From me: Fix a number of instances where the function prototype or
the function definition wasn't changed so there was a mismatch
thus causing Windows (but not gcc) compilation errors.
svn path=/trunk/; revision=32365
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
- conversation.[ch] - To support not setting port2 on matching a
conversation. This is used by protocols such as iSNS in which the client
registers a TCP/UDP port with the server for notifications and the server
sends notifications to this port from different source ports.
- packet-isns.c - Added support for handling zero-length TLVs and ESI & SCN
frames (when registering an SCN/ESI port, a conversation dissector is
setup).
svn path=/trunk/; revision=11320
than a pointer to a dissector function, as an argument.
This means that the conversation dissector is called through
"call_dissector()", so the dissector itself doesn't have to worry about
checking whether the protocol is enabled or setting
"pinfo->current_proto", so get rid of the code that does that in
conversation dissectors. Also, make the conversation dissectors static.
Get rid of some direct calls to dissectors; replace them with calls
through handles, and, again, get rid of code to check whether a protocol
is enabled and set "pinfo->current_proto" where that code isn't needed.
Make those dissectors static if they aren't already static.
Add a routine "create_dissector_handle()" to create a dissector handle
without registering it by name, if the dissector isn't used outside the
module in which it's defined.
svn path=/trunk/; revision=4281
of protocol-id-plus-datum pairs, so that multiple protocols can attach
information to the same conversation.
Dissectors that attach information to a conversation should not assume
that if they find a conversation it has one of its data attached to it;
the conversation might've been created by another dissector.
svn path=/trunk/; revision=3901
to imply that
1) conversations have source and destination addresses and ports
- they don't (if they did, they'd be monologues, not
conversations), they just have two address/port pairs for the
two endpoints, with one or more of the address or port in the
second pair possibly being wildcarded;
2) the first and second address or port argument to
"find_conversation()" or "try_conversation_dissector()" have
anything to do with the first or second address/port pair in
a conversation - they don't, the two arguments to those
routines are matched against *both* address/port pairs for a
conversation;
as otherwise people might think that they need to add flags to wildcard
the first arguments "conversation_new()" or "find_conversation()" (they
don't, they just have to pass the non-wildcarded address/port first and
then pass the wildcarded one, even if that means passing the destination
first and source second).
svn path=/trunk/; revision=3537
source *and* destination port and/or both the source *and* destination
address passed to "find_conversation()", because the packet for which
you're trying to find the conversation may be going in the opposite
direction to the packet for which the conversation was originally
created.
Create different hash tables for wildcarded conversations, to reduce the
number of "is this a wildcard?" tests done when doing hash lookups.
This is sufficient to allow the TFTP dissector to use conversations
rather than being special-cased in the UDP dissector, and may also be
sufficient to handle a similar problem with SMTP (request goes from
client IP X port Y to server IP Z's well-known port, reply comes back
from some other port on server Z to client IP X port Y), but further use
may reveal other changes that should be made.
svn path=/trunk/; revision=2525
Alexis La Goutte