The LLRP Standard 1.0.1 defines the ProtocolID Parameter as 8 bit value (see
LLRP Standard 1.0.1 document, page 138, AccessSpecParameter) but Wireshark
treats it as 16 bit value and therefore doesn't recognize the
EPCGlobalClass1Gen2 protocol type and marks the whole packet afterwards as
invalid.

svn path=/trunk/; revision=49991
This commit is contained in:
Evan Huus 2013-06-17 22:22:17 +00:00
parent 9fb168b2cc
commit 3398ae2aea
1 changed files with 2 additions and 2 deletions

View File

@ -1887,7 +1887,7 @@ dissect_llrp_parameters(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,
case LLRP_TLV_ACCESS_SPEC:
PARAM_TREE_ADD(accessspec_id, 4, ENC_BIG_ENDIAN);
PARAM_TREE_ADD(antenna_id, 2, ENC_BIG_ENDIAN);
PARAM_TREE_ADD(protocol_id, 2, ENC_BIG_ENDIAN);
PARAM_TREE_ADD(protocol_id, 1, ENC_BIG_ENDIAN);
PARAM_TREE_ADD(access_cur_state, 1, ENC_NA);
PARAM_TREE_ADD(rospec_id, 4, ENC_BIG_ENDIAN);
suboffset = dissect_llrp_parameters(tvb, pinfo, param_tree, suboffset, param_end);
@ -2799,7 +2799,7 @@ proto_register_llrp(void)
NULL, HFILL }},
{ &hf_llrp_protocol_id,
{ "Protocol ID", "llrp.param.protocol_id", FT_UINT16, BASE_DEC | BASE_RANGE_STRING, RVALS(protocol_id), 0,
{ "Protocol ID", "llrp.param.protocol_id", FT_UINT8, BASE_DEC | BASE_RANGE_STRING, RVALS(protocol_id), 0,
NULL, HFILL }},
{ &hf_llrp_can_do_survey,