[tcpdump-workers] Link type FlexRay
Hi, For which type of frame was the LINKTYPE_FLEXRAY 210 allocated? The file https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-common.c simply state that: /* * FlexRay automotive bus - http://www.flexray.com/ - as requested * by Hannes Kaelber . */ #define LINKTYPE_FLEXRAY 210 Also neither tcpdump, nor wireshark contains dissector code to dissect this packet. I am asking because I want to capture FlexRay frames using custom hardware. If no spec. is available I can provide a draft (FlexRay Frame-bitstream as captured from the bus + minimal header), example data and a dissector. If a spec. is available I will adhere to it. - Guenter ___ 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-15 21:35 GMT+01:00 Guy Harris : > > On Jan 15, 2016, at 10:44 AM, Guenter Ebermann > 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 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Link type FlexRay
> Am 20.01.2016 um 03:00 schrieb Guy Harris : > > On Jan 19, 2016, at 5:50 PM, Guy Harris wrote: > >> OK, so the new format is that the frame begins with a measurement header, >> which is followed by the bitstream from the bus? Yes. It only contains additional information. The idea is that the simplest measurement device (i.e. a device using a normal FlexRay controller), which only receives valid frames will also be able to generate the format. In this case no error flag will be set and only valid frames will be contained in the pcap(ng) file. >> Is the bitstream from the bus padded in that fashion? No. >> From the Wikipedia article on FlexRay (the first of the ISO standards the >> article mentions costs CHF 118, so I'm not going to buy them immediately): >> >> https://en.wikipedia.org/wiki/FlexRay >> >> a frame consists of some framing bits at each end of the frame, with each >> octet in the frame containing 2 bits of per-byte framing followed by the 8 >> bits of the octet. Would LINKTYPE_FLEXRAY/DLT_FLEXRAY frames include all of >> those bits? If so, where does the padding appear? > > (I'm assuming here that one packet in a pcap or pcapng file with type > LINKTYPE_FLEXRAY corresponds to a FlexRay frame, of the sort described at > > http://www.ni.com/white-paper/3352/en/#toc4 > > > under "Frame Format".) Yes, I will provide you with a PDF with a detailed description of the packet for further discussion. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Link type FlexRay
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 20:50 GMT+01:00 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? Yes, that is 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.) Yes. > 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? Yes. > 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. Yes I have added bit counting policy and byte order to the spec: https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14267 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 08.06.2016 um 23:10 schrieb Michael Richardson : > > Christian Rupp wrote: >> The Timestamp when tcpdump grabs the package off of the receiver is 36 >> seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when >> tcpdump grabs the package of the sender. resulting in an alleged One >> Way >> Delay of 36 seconds which wouldn't make any sense in that scenario, given >> that the software timestamping option and the -j adapter option both result >> in a ~ 100-200µs one way delay > > The timestamp on the sender is long before the hardware. > You are saying that the stamp is correct when you do not use the -j option? > > if that's the case, then it seems like it's the hardware which is > mis-stamping. Hardware timestamping of sending/receiving buffer descriptors is done by NIC. Configured by the NIC-driver (timer resolution of NIC timestamping clock). Setup by the user space application via kernel interface(s) [1] Therefore I would try to run a recent Linux kernel and a recent tcpdump. You may even change to another NIC for testing. [1] https://www.kernel.org/doc/Documentation/networking/timestamping.txt ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 09.06.2016 um 15:47 schrieb Michael Richardson : > > Guenter Ebermann wrote: >> Hardware timestamping of sending/receiving buffer descriptors is done >> by NIC. > > Receiving I understand. > > Are you sure that the hardware is going to timestamp sent packets, and then > turn around and send the back to the kernel? Yes, the driver must monitor tx descriptor consumption by hardware anyways. E.g. Freescale enhanced three speed ethernet controller (eTSEC) can timestamp send buffers - it writes the timestamps to the beginning of the buffer descriptor. You use such a controller feature to implement PTP (IEEE 1588). For Linux drivers supporting hardware timestamping see [1], chapter 5.3.2. The i350-T4, handled by Linux driver igb, is also supported (igb_ptp.c). It seems it does also timestamp tx buffers. [1] http://linuxptp.sourceforge.net/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 10.06.2016 um 00:13 schrieb Guy Harris : > > But that doesn't mean that the packets time stamped by the hardware when > transmitted will be delivered to the PF_PACKET sockets used by libpcap *with > the hardware time stamp as the time stamp*. > > In order make that happen, if hardware transmit time stamping is enabled for > a PF_PACKET socket: > > dev_queue_xmit_nit() will *NOT* deliver, to that socket, packets queued > for transmission; > > when the hardware says "I've transmitted these packets" (and > time-stamped them), the driver will take those packets and deliver them to > all PF_PACKET sockets with hardware transmit time stamping enabled? > > If those aren't done, then code processing packets from a PF_PACKET socket > will get a mix of packets with software time stamps (packets sent by the > machine on which that code is running) and hardware time stamps (packets > received by that machine). > > I don't see any obvious code in dev_queue_xmit_nit() to avoid delivering > packets to sockets that have requested hardware time stamping, so the first > of those statements doesn't appear to be true; is the second one true? Perhaps I am wrong, but it seems the drivers deliver the sent packets, including the hardware-timestamp, to the error queue of the socket. They all call skb_tstamp_tx() to do this, after the hardware has transmitted the packet and time-stamped it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 10.06.2016 um 01:35 schrieb Guy Harris : > > On Jun 9, 2016, at 4:09 PM, Guenter Ebermann > wrote: > >> >>> Am 10.06.2016 um 00:13 schrieb Guy Harris : >>> >>> But that doesn't mean that the packets time stamped by the hardware when >>> transmitted will be delivered to the PF_PACKET sockets used by libpcap >>> *with the hardware time stamp as the time stamp*. >>> >>> In order make that happen, if hardware transmit time stamping is enabled >>> for a PF_PACKET socket: >>> >>> dev_queue_xmit_nit() will *NOT* deliver, to that socket, packets queued >>> for transmission; >>> >>> when the hardware says "I've transmitted these packets" (and >>> time-stamped them), the driver will take those packets and deliver them to >>> all PF_PACKET sockets with hardware transmit time stamping enabled? >>> >>> If those aren't done, then code processing packets from a PF_PACKET socket >>> will get a mix of packets with software time stamps (packets sent by the >>> machine on which that code is running) and hardware time stamps (packets >>> received by that machine). >>> >>> I don't see any obvious code in dev_queue_xmit_nit() to avoid delivering >>> packets to sockets that have requested hardware time stamping, so the first >>> of those statements doesn't appear to be true; is the second one true? >> >> Perhaps I am wrong, but it seems the drivers deliver the sent packets, >> including the hardware-timestamp, to the error queue of the socket. > > And those don't just get delivered to the socket on which the packet was > sent, they get delivered to *all* sockets, including the PF_PACKET sockets > used for traffic capture? They are only delivered to the socket on which the packet was sent, not to all PF_PACKET sockets. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
