Hi!
Thank you for taking interest. I hate ARM's policy on this one as
well. If you would like to take a look at the documents, I'll be happy
to share them with you, write me a private email please.
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.
Next hiccup I encountered:
It's kindof obvious that I need to add a new data source into pcap. I
have found a way to "hack myself into" it, but have yet to find the
"good way". I could not find any good documentation on this on the
tcpdump site, and the mailing list is pretty passive.
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
(right now I am emulating CAN messages, to see how things work in
wireshark), and add a root-level dissector for it. I tried changing
the pcap_t structures linktype to something other than the default
DLT_CAN_SOCKETCAN, but then wireshark says that: "
I have read through the readme.developer as you suggested, but it does
not deal with how to add a new linktype, and how to add a dissector to
it.
If you would help me through this, I will try to find the time to
write a walkthrough for it - anyways it will be needed for my thesis.
Regards,
Ákos Vandra
On 11 December 2011 07:44, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Dec 10, 2011, at 10:23 PM, Guy Harris wrote:
>
>> So if those 16-byte frames have no internal structure (for example, you don't have a time stamp in each frame), but are just like, for example, the line boundaries in a hex dump, my inclination would be to have the pcap module break the byte stream into packets, even if that means that it needs to buffer a partial packet in a case where a 16-byte frame contains the beginning of a packet but not the end of the packet.
>
> This is why I love ARM Ltd so much - they just *love* saying "sorry, *that* document is only available to registered ARM customers":
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0029b/index.html
>
> I've inferred from other stuff that I've seen that the CoreSight Architecture Specification documents what the trace messages in question look like.
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe