On Apr 23, 2014, at 6:58 AM, Philip Rosenberg-Watt
<p.rosenberg-w...@cablelabs.com> wrote:
> I sent this to the list -- twice -- but it never showed up, so I'll just
> resend it to you. I don't know what's going on.
Moderation? Michael?
> I only put in the first "if" clause because some PON sniffer manufacturers
> may interpret the standard differently, and instead of dumping them out of
> the dissector entirely, I thought I could throw them a helpful error with
> a hint towards fixing their implementation. I believe the description
> should stay the same: that the preamble is 6 octets long with an optional
> idle (0x55) octet preceeding, depending on system alignment. 8 octets
> would be an error and needs correction in the PON sniffer implementation.
If that's what the description says, then the Wireshark dissector should treat
frames with two 0x55's as an error, rather than trying to work around them.
Wireshark or tcpdump dissectors shouldn't "extend" the description on
tcpdump.org; the whole point of those descriptions is to allow people to write
dissectors for a given LINKTYPE_/DLT_ value *without* having to look at tcpdump
or Wireshark source - if the description doesn't allow somebody to write a
program that handles those headers the same way tcpdump or Wireshark do,
because they also need to know about special processing tcpdump or Wireshark
does, then the description is incomplete and needs to be completed.
> Here's the problem as I see it: DPoE is simply an extension of (the unused
> and ignored) part of EPON, not a completely different format.
But it requires that the header be processed differently; "completely" is
irrelevant - the purpose of a LINKTYPE_/DLT_ value is to indicate to the code
processing a capture how it should process the header indicated by the value.
> Another problem is that EPON and DPoE system equipment can interoperate to
> some level, and the PON sniffer has no way of knowing whether the traffic
> it's seeing is DPoE or regular EPON. There would be no determine which
> LINKTYPE_ to put in the pcap file without human intervention.
...
> A piece of equipment
> sniffing the data should already know what it's capturing is EPON.
Unless I'm missing something, the first of those paragraphs says the hardware
*doesn't* know whether the octet in question is 0x55 or an encryption field, so
it doesn't know whether it's capturing standard EPON or EPON with the DPoE
encryption extension.
If that's the case, so that a human has to indicate how the octet should be
interpreted in any case, a single LINKTYPE_/DLT_ value is OK.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
