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
HIP dissector: PUZZLE and SOLUTION parameters variable size
According to specifications, puzzle and solution parameters carry Random #I and
#J fields that has variable length depending of the Hash function. The fields
are recognized with a fixed value of 8 bytes.
The #I and #J fields should be determined depending of the TLV size.
See http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-08#section-5.2.5 .
svn path=/trunk/; revision=42140
Add RFC5933 : Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
Add RFC6605 : Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
svn path=/trunk/; revision=42124
Unable to display the correct IEEE802.11 MCS data rates due to header definition
The problem is due to the ieee_802_11_phdr.data_rate is defined as guint8,
since this variable is counting number of 0.5Mbps units, any datarates which is
higher than 255Mbps would get wrapped up. In the above example, only the lower
8bit value will be put into the ieee_802_11_phdr which is 0x04 and result in
the incorrect 2Mbps display.
There are 802.11n WLAN product is capable to transmit @450Mbps, we should fix
this data_rate from guint8 to guint16.
#BACKPORT
svn path=/trunk/; revision=42123
return the right error code and information string.
InfoVista bought Accellent Group, and, at least according to the
InfoVista Web site, it's "5View", not "5Views".
svn path=/trunk/; revision=42119
802.11s Decoding Bug (Mesh Control Field)
Wrong offset use to dissector Mesh Extended Address(bug from the revision 39314)
svn path=/trunk/; revision=42105
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
uses it once it's filled in.
From Evan Huus: in scan_local_interfaces(), pass NULL to
capture_interface_list(), as we don't use the error string (and don't
free it, either).
In fill_capture_box(), for CANT_GET_INTERFACE_LIST, include the error
string in the report, and free it, in all cases, when we're done with
it.
svn path=/trunk/; revision=42089
Anders Broman