Fix to honour the Response Bit/Opcode implementation,
as e.g. a map response opcode is not 129 as per 1000 0001 but should be
Response bit =1 / Opcode =1.
* Rename opcode variable to ropcode (and pcp_ropcode_vals)
* Use pcp_opcode for hf_pcp_opcode
* Add hf for R item (and add tfs)
* Fix bitmask for opcode
Also fix warning found by encoding-args tool.
svn path=/trunk/; revision=49445
As per RFC 6887 the response header has 96bit reserved bit, not 64.
Without the attached patch, the PCP Responses are parsed incorrectly
svn path=/trunk/; revision=49202
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
The Port Control Protocol overtakes the NAT-PMP IANA UDP ports, but is backwards compatible enough to trigger off of the version number (NAT-PMP is version 0). NAT-PMP can still use Decode As.
Left the two dissectors with their own unique display filters despite a few overlapping fields. Didn't want it to turn into a BOOTP/DHCP situation.
svn path=/trunk/; revision=47405
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
Bill Meier