On Sep 14, 2011, at 12:31 AM, <[email protected]> wrote:
> Yes, that's right, these are the sequences described in sections 3.2.1 and
> 3.2.2. Even though, in hexadecimal notation this would be 0x55 0x55 0x55 0x55
> 0x55 0x55 0x55 and 0xd5, respectively (as denoted in section 3.3)
Sigh. I guess the bottommost bit is shown first because it's the first bit
transmitted, which probably makes sense to hardware people; I guess we software
people who usually see the high-order bit shown first just have to remember
that IEEE standards do things differently.
In any case, I've assigned 240 as
DLT_ETHERNET_HILSCHER/LINKTYPE_ETHERNET_HILSCHER, for non-transparent packets
(with the 4-byte pseudo-header before the Ethernet header, but without the
preamble or SFD), and 241 as
DLT_ETHERNET_HILSCHER_TRANSPARENT/LINKTYPE_ETHERNET_HILSCHER_TRANSPARENT, for
transparent packets (with the 4-byte pseudo-header followed by the 7-byte
preamble, followed by the 1-byte SFD, followed by the Ethernet header), and
checked that, including filter support, into the libpcap trunk and 1.2 branch.
(That's 11110000 and 11110001, not 00001111 and 10001111. :-) :-) :-))
I'll add tcpdump support for printing those packets (it'll ignore the
pseudo-header and, for DLT_ETHERNET_HILSCHER_TRANSPARENT, the preamble and
SFD), and add the two new link-layer types to
http://www.tcpdump.org/linktypes.html
along with a page containing your description of the pseudo-header (but I'll
leave the "transparent" bit out, as that's indicated by the link-layer header
type).-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
