Replace with conversation API that limits the "endpoint" to a single
uint32 value.
The intention is to eventually have "layered" endpoints, because circuit_id
was used in cases where src/dest port have already been populated (and
are used for layers above). Those src/dest ports should just be treated
as just another endpoint, but we currently only have support for one.
Change-Id: Ic6aa7ef0241275aa4dfde9459194369b48c72960
Reviewed-on: https://code.wireshark.org/review/24369
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I8752123a740c47f9328e0144624d4fbf4e200165
Reviewed-on: https://code.wireshark.org/review/24314
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Id007a3df5442cf4d21263acb17303b6d735aaa7d
Reviewed-on: https://code.wireshark.org/review/24311
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add the few necessary conversation APIs to make conversion possible.
Change-Id: I775f23005c48cacd2be342bdc704af4738f0789c
Reviewed-on: https://code.wireshark.org/review/24310
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add endpoint information to the packet_info structure for dissectors
to potentially use as their data to create conversations.
This patch includes a simple "example" of using conversation_create_endpoint
with TDMoP. The assignment of the PT_TDMOP "port type" has been replaced by
setting ENDPOINT_TDMOP within the endpoint structure. Then when subdissectors
of TDMoP call find_or_create_conversation(), it implicitly picks up the
conversation information set by TDMoP
Change-Id: I11dc29989cccd3b0f0349ee901babb455ca02d19
Reviewed-on: https://code.wireshark.org/review/24190
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Andrew Chernyh <andrew.chernyh@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
For the moment this mirrors the port_type enumeration (PT_XXX), but the
intent is to move away from using "port types", eliminating most (if not
all)
Added conversation_pt_to_endpoint_type() so that conversations deal with the
correct enumeration. This is for dissector that use pinfo->ptype as input
to conversation APIs. Explicit use of port types are converted to using
ENDPOINT_XXX type.
Change-Id: Ia0bf553a3943b702c921f185407e03ce93ebf0ef
Reviewed-on: https://code.wireshark.org/review/24166
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
The intention is to make it more transparent when making a switch
to an "endpoint" over address/port combination.
Change-Id: Ic424c32095ecb103bcb4f7f4079c549de2c8d9c4
Reviewed-on: https://code.wireshark.org/review/24148
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
It was duplicated in GTK, so just make it public (at least for now)
Change-Id: I89d985b2d42f0edb1c535a65a97b132920dedbcd
Reviewed-on: https://code.wireshark.org/review/24146
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Convenience function to add the same parameters to find_conversation as
find_or_create_conversation.
Change-Id: I3a92541cb9c1e827a9de8248825636debbd989cd
Reviewed-on: https://code.wireshark.org/review/24118
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Simplifies cleanup because wmem can handle the memory cleanup.
Change-Id: Idc6a9bfe5f23c83b59a5278a64b9fb706862342d
Reviewed-on: https://code.wireshark.org/review/20042
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
into consideration.
This makes it possible to differentiate between packets on different
vlans and can be expanded to handle tunnels.
Change-Id: Id36e71028702d1ba4b6b3047e822e5a62056a1e2
Reviewed-on: https://code.wireshark.org/review/13637
Reviewed-by: Anders Broman <a.broman58@gmail.com>
According to RFC 6062, once the connection is established, data is sent as-is
To stop the STUN dissector from interfering, add the ability to specify a starting
frame for a conversation dissector and use it
Bug: 11641
Change-Id: I65ca96bddacf70444009c0642ea22173fa68992e
Reviewed-on: https://code.wireshark.org/review/11372
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
(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
Michael Mann