Re: New LINKTYPE_ for EPON

[Michael Richardson <mcr () sandelman ca>]

Guy Harris <guy () alum mit edu> 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?

Nothing in the local queue.
Nothing in spam trap.  That suggests that your email failed SPF or something
that caused it to never get to lists.tcpdump.org.  Send mail logs please...

    >> 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.

+5

    >> 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.

But, if the human has to say which thing is being captured, shouldn't we want
to capture what the human thought as different types?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on rails    [

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers