On Dec 11, 2011, at 4:45 AM, Akos Vandra wrote:
> FYI: Anyways the format of those 16-byte frames are - pardon the
> language - fucked up real bead, and a pain in the ass to understand
> and decode. Anyways, to answer your questions: they do not contain any
> interesting data, only that hey, here are another bunch of bytes, and
> its sole purpose is to keep up synchronization between the target and
> the tracer. If there is not enough data to be sent when the target
> finishes sending the last 16-byte frame, it pads them out with
> "zeroes". Actually it's not only zeroes, because of the lovely
> encoding of it, but practically they are padding bytes. Timestamp
> information is included within these 16-byte frames, along with the
> messages.
OK, so does that mean that the time stamp for the 16-byte frame applies to all messages that begin in that frame? For example, if a frame has two complete messages and the beginning of a third message, would the time stamp for the frame apply to all three of those messages?
If so, my inclination would be to have libpcap deliver messages rather than frames, and have it provide, for all messages that begin in a frame, the time stamp of the frame for the time stamp of the message.
> I suppose (looking at only the sources, and mostly the socketcan
> libpcap source) that I need to add a new linktype to my data source
Yes, you need to get a new link-layer header type value assigned, for libpcap to return.
You'd ask for that on the tcpdump-workers list; you'd need to have a description of the messages. Right now, that's being discussed in this thread, so we might as well come up with the right message format here before you ask for the link-layer type.
