I'm reasonably sure that I introduced this bug and I apologize for the problems
with my previous patch. The problem is that I did not use all of the seen
keys, I used all except the first key, which in a case of one key is none.
The attached patch fixes the error.
svn path=/trunk/; revision=29843
struct _GString
{
gchar *str;
gsize len;
gsize allocated_len;
};
And:
struct _GArray
{
gchar *data;
guint len;
};
We only accessed the first two fields of the GString struct.
svn path=/trunk/; revision=29841
The attached patch improves NHRP dissection and encompasses the following
changes:
1) Now displays Request ID and CIE Reply code or Error code in Info column.
2) Added support for RFC 2520 and RFC 2735 extensions and error codes.
References:
-> http://www.ietf.org/rfc/rfc2520.txt?number=2520
-> http://www.ietf.org/rfc/rfc2735.txt?number=2735
Note: Cisco's NAT Address Extension conflicts with RFC 2735's published
Device Capabilities Extension. Both are assigned type 9. As such, I have had
to add some heuristics to differentiate between them. It should be reliable
though since the former carries a CIE with length > 8 bytes, and the latter a
fixed-length payload of 8 bytes.
3) A few fields previously not filterable now are: hf_nhrp_hdr_op_type,
hf_nhrp_hdr_version and hf_nhrp_error_code.
4) Added support for authentication and vendor-private extension header decode.
NOTE: The authentication extension has been added according to RFC 2332. In
practice, it seems that at least with certain Cisco equipment (I tested with
cisco 2851 IOS version 12.4(15)T), they use their own non-standard
authentication extension format. Because of this, Cisco's version of the
extension will likely either be displayed a little differently than one may
expect or be indicated as being mal-formed ... because in reality, it is.
5) Utilizes expert info in a couple more places to indicate mal-formed packets.
Cisco's Error Indication packet, for example, violates RFC 2332 Section 5.2.7
by including extensions in the Error Indication packet as well as by including
erroneous data following the End Extension. Both cases are reported via expert
info now. Previously, at least with the case of the erroneous data following
the End Extension, the packet would almost certainly have been marked
mal-formed anyway. I now just prevent Wireshark from even attempting to decode
the non-sensical mess.
svn path=/trunk/; revision=29833
http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/StartupItems.html
"Table 1 StartupParameters.plist key-value pairs
Key Type Value
Description String A short description of the startup item,
used by administrative tools.
Provides Array The names of the services provided by this
startup item. Although a startup item can
potentially provide multiple services, it is
recommended that you limit your startup items
to only one service each."
Fix "Provides" to be the name of the service, not a description of the
helpful operations that it provides.
(Propagated from tcpdump.org git repository.)
svn path=/trunk/; revision=29830
We fill out the COL_DSTIDX column by using 'pinfo->dst_idx'. This member is only set by the MDS Header dissector based on 'mdshdr.dstidx'. So remove COL_DSTIDX and migrate to 'mdshdr.dstidx' custom column.
svn path=/trunk/; revision=29795
We fill out the COL_SRCIDX column by using 'pinfo->src_idx'. This member is only set by the MDS Header dissector based on 'mdshdr.srcidx'. So remove COL_SRCIDX and migrate to 'mdshdr.srcidx' custom column.
svn path=/trunk/; revision=29794
We fill out the COL_RXID column by using 'pinfo->rxid'. This member is only set by the Fibre Channel dissector based on 'fc.rx_id'. So remove COL_RXID and migrate to 'fc.rx_id' custom column.
svn path=/trunk/; revision=29793
Jaap Keuter