[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3950

           Summary: NHRP improvements
           Product: Wireshark
           Version: SVN
          Platform: All
               URL: http://www.ietf.org/rfc/rfc2332.txt?number=2332
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: christopher.maynard@xxxxxxxxx



Chris Maynard <christopher.maynard@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3575|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=3575)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3575)
NHRP improvement patch

Build Information:
SVN 29554
--
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.

Testing:
You can use the sample capture file posted with bug #1997
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1997).  If desired, I can
also post some additional sample capture files that depict various other
extensions.

TBD:
Some hf_xyz's are unused.  I indicated them as being unused.  Either some
additional improvements can be made with them or if they're not needed, they
could be removed.

I have asked our Cisco representative for information regarding their otherwise
undocumented extensions but thus far I have not received anything.  I don't
know if Cisco will ever publish their extensions or not, but if they do or at
least make them more publicly known, then I'm sure there will be additional
work to add dissection support for them ... and possibly more heuristics to try
to resolve conflicts with published RFC extensions.

I don't know how/where to add the RFC 2735 VPN encapsulation header.  If we can
add that somewhere, then we can hand-off dissection from that header to the
NHRP dissector to decode the NHRP payload.

I wanted to add request/response tracking by making use of the Request ID in
the request and matching it with the same Request ID in the reply or Error
Indication packet as the case may be.  However, it seems that the conversation
API is only applicable to TCP or UDP based protocols and NHRP is encapsulated
in a GRE packet, so it doesn't look like I can use conversations.  Any idea how
else to match a Request to a Reply if not by conversations?


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.