On Dec 8, 2014, at 1:04 PM, Christopher Smith <Christopher.Smith@xxxxxxxxx> wrote:
> The easier way to explain what I am asking? Here’s the closet to what I am asking (http://www.unleashnetworks.com/blog/?p=307 ), found it yesterday after posting. Notice the graphics showing packet granularity @ 25k??
If you mean the picture at
http://www.unleashnetworks.com/blog/wp-content/uploads/2011/05/superp2.jpg
it's not showing link-layer packets or HTTP requests or responses, it's just showing whatever chunks the OS handed to whatever program captured the traffic.
The Linux kernel deferred TCP segmentation until *after* the point at which packets are delivered to the PF_PACKET socket (that's what libpcap - the packet capture library tcpdump, Wireshark, and other programs use for packet capture - uses to read packets on Linux). So what gets delivered to the socket, and thus to whatever program wrote the pcap, wasn't a sequence of link-layer frames, it was a single big chunk that, later in the networking stack, got split into TCP segments sent as link-layer frames.
Unfortunately, no information about how that chunk eventually gets split into TCP segments gets delivered along with the chunk, so no program reading the pcap file has any hope whatsoever of finding out from the pcap file what frames were actually transmitted on the network.
If you download the superpackets.tcpd capture (I'm guessing from ".tcpd" that it was done with tcpdump), load it in Wireshark, and sort the "Length" column (present by default, at least in newer versions of Wireshark), you'll see a similar display to what they showed in Unsniff.
This, however, is different from what you spoke of. You said
For example, if an HTTP response is segmented into multiple 1514 byte frames – say 10 frames, how do I “tweak” Wireshark so the fully 15140 bytes appears in one “packet”
which sounds as if you have a capture with individual link-layer frames, not a capture with un-segmented chunks as the person in the blog post had.
> I have used Wireshark for a while now and find it both an excellent and fascinating tool. However, I am getting the sense it filters extremely well, but doesn’t …. coalesce so easily?
It coalesces *very* easily. That's what all the packet reassembly stuff you read about in Wireshark does, unless some particular form of reassembly has been disabled by the user, or only some of the fragments/segments to be reassembled are present in the capture, or Wireshark is refusing to reassemble packets with bad checksums.
> Like, a method to parse through a trace to present its granularity on protocols vs frames?
So do you mean that you want a display that shows, for example, each HTTP request or response as a single line in the summary, with, for example, the length field showing the length of the request or response as a whole, with the packet details at a lower level (link-layer frame, IP, TCP) hidden?
