Skip to content

Conversation

@kayoub5
Copy link
Contributor

@kayoub5 kayoub5 commented Dec 24, 2020

Context

CC @LarsVoelker

@infrastation
Copy link
Member

Please make the new page appear in htmlsrc/linktypes (without duplicate copies of the header and the footer) so regen_html_pages.sh can pick it up and produce the file in linktypes. Likewise, please modify htmlsrc/linktypes.html instead of linktypes.html.

@kayoub5
Copy link
Contributor Author

kayoub5 commented Dec 24, 2020

@infrastation done

@infrastation
Copy link
Member

Thank you. In the proposed changes did you mean DLT_FLEXRAY instead of DLT_IPMB_LINUX?

@kayoub5
Copy link
Contributor Author

kayoub5 commented Dec 24, 2020

@infrastation yes, fixed.

@kayoub5 kayoub5 marked this pull request as ready for review December 25, 2020 01:56
@kayoub5
Copy link
Contributor Author

kayoub5 commented Dec 27, 2020

@infrastation PR ready.

@infrastation
Copy link
Member

Thank you. I have squashed these commits and rebased on the current master branch. Please mind that www.flexray.com is no longer a relevant web-site, also the HTML version has lost the "FlexRay Frame Data Packet" header altogether and the notion of size range in a few other headers. Would you like to put that right before merging?

@kayoub5
Copy link
Contributor Author

kayoub5 commented Dec 27, 2020

@infrastation link and headers fixed, ready to merge.

@infrastation infrastation merged commit eb91033 into the-tcpdump-group:master Dec 28, 2020
@infrastation
Copy link
Member

Thank you.

@infrastation infrastation self-assigned this Dec 28, 2020
@guyharris
Copy link
Member

Do you know whether that matches what Hannes Kaelber intended when he asked for LINKTYPE_FLEXRAY/DLT_FLEXRAY?

@kayoub5
Copy link
Contributor Author

kayoub5 commented Mar 19, 2021

@guyharris No, Hannes Kaelber used the DLT_FLEXRAY for a limited scenario and approved the change of the layout when he was contacted about it.

The new layout is being actively used, and is supported by Wireshark.

See https://lists.sandelman.ca/pipermail/tcpdump-workers/2016-January/000476.html

> 2016-01-15 21:35 GMT+01:00 Guy Harris <guy at alum.mit.edu>:
>
> On Jan 15, 2016, at 10:44 AM, Guenter Ebermann <guenter.ebermann at googlemail.com> wrote:
>
> I don't know whether Hannes still works at X2E.  You might want to try sending an e-mail to him asking whether a format for DLT_FLEXRAY was ever defined - and, if it has, asking him to send me a copy so that I can add it to the link-layer header types page:
>
>         http://www.tcpdump.org/linktypes.html
>
> (and, if any of the *others* were defined, to send those to me as well).
>
> If mail to him bounces, you could try contacting X2E to see if that information is available, or if they ever supporting writing out files in pcap or pcapng format.
>
> If they never wrote files out with a link-layer header type of 210 for DLT_FLEXRAY/LINKTYPE_FLEXRAY, then you can use it for your own purposes - send us the spec and I'll add it to the link-layer header types page.
>
> If they did, but they don't tell you what format they use, we can create a new LINKTYPE_/DLT_ value for your format, and provide a public specification for that one.

I asked Hannes about DLT_FLEXRAY.
He told me that they currently dont use pcap for FlexRay and have only
used it in a limited scenario and that we are free to change the
layout.
The format represented the bitsream from the bus 1:1 without an
additional header.
The only deviation was the padding: the data was padded to align to 4
byte boundaries.

This is my suggestion for an extension:

I want to extend the frame by a "measurement-header": This header is
added by the measurement device. It contains one bit for the FlexRay
channel (A or B), a "data-type" enumeration and error-flags.

Error-flags will be all kind of decoding errors which may be detected
during capture of a FlexRay frame. That is: TSS, FSS, BSS, or FES
violations. Header CRC or Frame CRC errors and all kind of
"short-item-counts" that is, if not all bytes of the frame-bitstream
could be captured.

One enum-value of the "data-type" will be for a "data-frame", whereas
a data frame would have exactly the same coding as on the FlexRay bus.

The second enum-value of the "data-type" will be a "flexray-symbol",
which contains the bitlength information of the captured FlexRay
symbol (used for CAS and Wakeup).

BR
Günter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants