tcpdump mailing list archives
Re: New LINKTYPE_ for EPON
From: Michael Richardson <mcr () sandelman ca>
Date: Wed, 23 Apr 2014 20:38:37 -0400
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
Current thread:
- New LINKTYPE_ for EPON Philip Rosenberg-Watt (Apr 18)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 18)
- <Possible follow-ups>
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 21)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 21)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 22)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 22)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 23)
- Re: New LINKTYPE_ for EPON Michael Richardson (Apr 23)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 23)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 23)
- Re: New LINKTYPE_ for EPON Philip Rosenberg-Watt (Apr 24)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 24)
- Re: New LINKTYPE_ for EPON Guy Harris (Apr 24)
- Re: New LINKTYPE_ for EPON Philip Rosenberg-Watt (Apr 25)