Change-Id: I4f1078b20f41800f72a751612703ad0d4c2ae87b
Reviewed-on: https://code.wireshark.org/review/6323
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Ief00f09225805c6c7488d92f8aa5b59c21575788
Reviewed-on: https://code.wireshark.org/review/3464
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
In commit 4afd70d ("Use g_hash_table_new_full to free some values"), the
hashtable gained a destroy handler which frees memory. This
inadvertently destroyed a conversation during key updates.
Fix this by not calling _remove (and thereby calling the destroy
handler), but use _steal instead. (Suggestion by Evan Huus).
Bug: 10263
Change-Id: I9fa7f5a697599f42894d38718b00b9c0c1b57004
Reviewed-on: https://code.wireshark.org/review/2924
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Evan Huus <eapache@gmail.com>
Fixes a good 80-90KB of leaks in certain cases.
Bug: 10261
Change-Id: I81d57ac67219e730b03649b9fdfc2306807bdb97
Reviewed-on: https://code.wireshark.org/review/2879
Reviewed-by: Anders Broman <a.broman58@gmail.com>
There have been enough gnarly bus in sip/sdp/rtp that it needs
to have good debug printing. Using a debugger isn't good enough
because there's interaction across multiple frames and it's too
hard to follow what's going on without real printed data history.
Change-Id: Ifb5bb1fb580be81f988569ece79d238a9c030c34
Reviewed-on: https://code.wireshark.org/review/688
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Reviewed-by: Anders Broman <a.broman58@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>
no longer get to check both conversation directions at once "for free" because
the two orderings actually result in different hashes. Do them one at a time.
Sorry Anders, this may or may not cancel out some of the performance gain you
were looking for. Either way, the new hash function is still an improvement.
Fixes bidirectional conversation lookup, which was conveniently showing up as
a DTLS decryption failure in the test suite. Go figure.
svn path=/trunk/; revision=52084
temporary address structure for the port-numbers so we can use the same macro,
reducing duplication further.
Add modelines.
svn path=/trunk/; revision=52081
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
Do the right thing with conversation hash chains.
Adds two new functions: conversation_insert_into_hashtable() and
conversation_remove_from_hashtable() that do the right thing with conversation
hash table chains and ordering and all that. Converts conversation_new(),
conversation_set_addr2() and conversation_set_port2() to use the new functions.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7085
svn path=/trunk/; revision=42104
has been called.
In the conversation cleanup routine, free the GSlist for any proto_data which
may have been hanging off the (se_allocated) conversation.
svn path=/trunk/; revision=39484
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
does (i.e., it will add the address bytes to the value that's already
there - it will not initialize the value, so you have to clear it before
doing any hashing).
svn path=/trunk/; revision=21578
the supplied patch fixes a problem where the options value should really be used from the conversation found (using
conversation_lookup_hashtable(...) to create a new conversation based on the already stored conversation template (the CONVERSATION_TEMPLATE bit is set in the stored conversation) rather from the options argument passed to the function(s).
This solves a problem that otherwise shows itself where "DISSECTOR_ASSERT(!(conv->options & CONVERSATION_TEMPLATE) && "Use the conversation_create_from_template function when the CONVERSATION_TEMPLATE bit is set in the options mask");" fails sometimes.
svn path=/trunk/; revision=18825
fix bug in conversation_delete_proto_data
second argument to g_slist_remove() is a pointer to the data, not a GSlist containing a list of such pointers.
svn path=/trunk/; revision=14755
This is very naughty and will cause problems when we have assigned a dissector to a dynamic port using conversation_set_dissector().
To make ethereal handle this case I have changed the try_conversation_dissector() to allow it to fail and return 0, meaning yes there is indeed a protocol registered for this conversation but that protocol rejected this packet.
(which only happens for "new" style dissectors, "old" style dissectors will never reject a packet that way)
When this happens the decode_udp_port() helper will still allow other dissectors to be tried, in the hope that the conversation is now used for some other protocol and thus someone else might be able to decode the packet.
Update SNMP and TFTP dissectors to check that even if there already is a conversation but that conversation does NOT have snmp/tftp registered as the dissector for it, then create a new conversation anyway and attach the proper dissector.
Since ethereal keeps track of which frame number a conversation started in, this actually works really well.
svn path=/trunk/; revision=14345
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
Michael Mann