(Resending to the list.)
On Apr 22, 2014, at 1:28 PM, Philip Rosenberg-Watt
<p.rosenberg-w...@cablelabs.com> wrote:
> Great! I just submitted my Wireshark dissector with the appropriate
> LINKTYPE.
Hmm.
That dissector does
/* Start_of_Packet delimiter (/S/) can either happen in byte 1 or byte 2,
* making the captured preamble either 7 or 6 bytes in length. If the
* preamble starts with 0x55, then /S/ happened in byte 1, making the
* captured preamble 7 bytes in length.
*
* If for some reason the sniffer adds two bytes of 0x55 idle before SLD,
* do not change the offset, but raise an error later.
*/
if (tvb_get_ntohs(tvb, 0) == 0x5555) {
offset -= 0;
} else if (tvb_get_ntohs(tvb, 0) == 0x55D5) {
offset -= 1;
} else if (tvb_get_ntohs(tvb, 0) == 0xD555) {
offset -= 2;
} else {
item = proto_tree_add_item(tree, proto_epon, tvb, offset, 0, ENC_NA);
expert_add_info(pinfo, item, &ei_epon_sld_bad);
return 0;
}
The code current starts out with offset = 0, and appears to always add 2 to
offset; I'll suggest replacing that with
/* Start_of_Packet delimiter (/S/) can either happen in byte 1 or byte 2,
* making the captured preamble either 7 or 6 bytes in length. If the
* preamble starts with 0x55, then /S/ happened in byte 1, making the
* captured preamble 7 bytes in length.
*
* If for some reason the sniffer adds two bytes of 0x55 idle before SLD,
* do not change the offset, but raise an error later.
*/
if (tvb_get_ntohs(tvb, 0) == 0x5555) {
offset += 2;
} else if (tvb_get_ntohs(tvb, 0) == 0x55D5) {
offset += 1;
} else if (tvb_get_ntohs(tvb, 0) == 0xD555) {
offset += 0;
} else {
item = proto_tree_add_item(tree, proto_epon, tvb, offset, 0, ENC_NA);
expert_add_info(pinfo, item, &ei_epon_sld_bad);
return 0;
}
and subtract 2 from the offsets passed to code adding items to the protocol
tree, to make the code a bit more understandable (in terms of offsets from the
beginning of the packet data).
This suggests that the description of LINKTYPE_EPON needs to be changed, to
indicate that:
the preamble in the capture file is between 6 and 8 octets long, *not*
a fixed 6 octets long;
if it begins with 0x55 0x55, the preamble is 8 octets long, and what
follows the 0x55 0x55 is the 6 octets in question;
if it begins with 0x55 0xD5, the preamble is 7 octets long, and what
follows the initial 0x55 is the 6 octets in question;
if it begins with 0xD5 0x55, the preamble is 6 octets long, and is the
6 octets in question.
In addition, the code *still* has a preference to indicate whether the octet
preceding the mode/LLID is just 0x55 or an encryption enabled/key ID field.
Either
1) there should be *two* LINKTYPE_ values - LINKTYPE_EPON, in which
that field is just part of the preamble, and LINKTYPE_DPON or
LINKTYPE_CABLELABS_DPOE, in which it's an encryption enabled/key ID field
or
2) if that field will *never* have the value 0x55 in a DPoE capture,
and will *always* have the value 0x55 in a regular EPON capture, use that to
determine what the field is.
(Any time a tcpdump link-layer printer for a given DLT_ value, or a Wireshark
dissector for a WTAP_ENCAP_ value, requires a preference/command line option to
control how the octets of the link-layer header are parsed, God kills a kitten.
Please, think of the kittens.)
(Slide 5 of
http://www.ieee802.org/3/epoc/public/mar12/schmitt_02_0312.pdf
says, emphatically, that this "Is NOT DOCSIS over fiber", so I assume what
follows the DPoE preamble is an Ethernet frame, *not* a DOCSIS frame.)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
