On Dec 10, 2011, at 5:11 AM, Sake Blok wrote:
> The task of libpcap is to capture frames and hand each frame to wireshark, no dissection is done by libpcap, that is wiresharks job.
Deciding what a "frame" is for a particular capture, however, could be libpcap's job. Whether those 16-byte frames constitute interesting frames from the point of view of the protocol is questionable; if they have no internal structure of their own, just "here's the next 16 bytes of data", I'd be inclined not to consider them interesting.
If the arrival timestamps of the frames are interesting, *then* it might be worth having libpcap treat the 16-byte frames as such. Otherwise, that's not so clear.
That does raise the question of what happens if, for example, one trace message, less than 16 bytes long, is sent, and then another message that fills up a 16-byte frame is sent a significant amount of time later; does whatever's reading the trace truly not see the first trace message until the second trace message is sent? If so, this sounds like something that isn't as useful as it could be if you're doing live tracing of an ARM-based system - especially if the trace messages don't themselves include time stamps, as in that case you have no idea when the event described by the first of those trace messages happened!
