Re: New LINKTYPE_ for EPON

[Guy Harris <guy () alum mit edu>]

On Apr 23, 2014, at 6:58 AM, Philip Rosenberg-Watt <P.Rosenberg-Watt () 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