Re: [tcpdump-workers] Link type FlexRay

2016-01-20 Thread Guenter Ebermann 
Hi,

I have a first draft of the packet-specification available:
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14264

The specification is available as an attachment to the following
wireshark bugzilla entry:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12033

This first draft does not contain a packet for flexray-symbols yet.
This will be added soon.

The idea of this packet is to define a universal specification for
FlexRay monitoring devices, independent of the vendor of the device.
Please feel free to comment.

BR,
Günter
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Link type FlexRay

2016-01-20 Thread Guy Harris 
On Jan 20, 2016, at 7:38 AM, Guenter Ebermann  
wrote:

> I have a first draft of the packet-specification available:
> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14264

So it looks as if the extra low-level framing bits aren't included; is that 
correct?

The Frame Header is 16 bits; do bits 15 through 8 appear in the first octet, 
with bits 7 through 0 being in the second octet?  (I'm assuming that, in the 
octet with bits 15-8, bit 15 is the high-order bit and bit 8 is the low-order 
bit, and that, in the octet with bits 7-0, bit 7 is the high-order bit and bit 
0 is the low-order bit.)

Similarly, the Payload preamble indicator is 24 bits; are the three octets of 
the PPI, in order, the octet with bits 23-16, the octet with bits 15-8, and the 
octet with bits 7-0?

Presumably, as the extra low-level framing bits aren't included, the Data 0 
through Data n bytes just appear as octets following the PPI.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers