Oops, pressed the send button by accident.
The missing wireshark error is:
Invalid capture filter "" for interface trace1!
That string isn't a valid capture filter (unknown data link type 292).
See the User's guide for a description of the capture filter syntax.
Also, here's a syntax of what I've acheived this far:
http://sem.sch.bme.hu/~akos/Screenshot-1.png
And here you can find my not-so-pretty code, it has to be cleaned up a
lot, right now I am in the phase "hmm... let's see if that will
work..." :)
http://pastebin.com/fVnrEfpr
Regards,
Ákos Vandra
On 11 December 2011 13:45, Akos Vandra <axos88@xxxxxxxxx> wrote:
> 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
