Re: N in 1 packets

[Guy Harris <guy () alum mit edu>]

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!
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe