On Oct 16, 2012, at 7:47 AM, Perry Smith <pedzsan@xxxxxxxxx> wrote:
>
> On Oct 15, 2012, at 9:20 PM, Guy Harris wrote:
>
>>
>> On Oct 15, 2012, at 6:41 PM, Perry Smith <pedzsan@xxxxxxxxx> wrote:
>>
>>> I'd be happy to supply a sample. Can you suggest a way to get it to you?
>>
>> The best way would probably be to file a bug at
>>
>> http://bugs.wireshark.org/
>
> I can do that but wanted to point out that there are three ways to run iptrace.
>
> One is just iptrace. Wireshark knows how to use those file just fine.
Wireshark knows how to read iptrace files. Whether it knows how to handle "sliced" packets in iptrace files is another matter - and whether iptrace files can handle sliced packets is still another matter.
> Second is iptrace with -B. This is where the problem arises. -B uses the bpf filter from tcpdump but formats the output as an iptrace file. This is where we see the problem.
The difference there isn't the file type, it's the capture mechanism; what the iptrace man page says is
-B Uses bpf for packet capture.
"bpf" can refer either to the packet capture mechanism or to the filtering language that was originally implemented in that capture mechanism (but was subsequently used in other capture mechanisms, such as Linux PF_PACKET sockets and WinPcap's driver and DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX's capture mechanism).
In this case, it probably refers to the former, which is implemented in AIX. My guess is that iptrace uses some other mechanism by default, but can also use BPF.
The manual page also says
-S snap_length Specifies the snap size (how much of each packet is actually captured from the wire) when you run the iptrace daemon with the -B flag (the bpf support). The command iptrace -S 1500 /tmp/iptrace.dump will limit captured packet size to 1500 bytes. The default is 80 bytes.
so the other mechanism probably doesn't support "slicing" frames, but BPF does.
"Just iptrace" doesn't produce sliced frames, so, for iptrace without -B and without -T, it doesn't matter whether iptrace format handles sliced frames well (as in "provides both the sliced length and the unsliced length) or not. That's why it works with Wireshark.
> Third is iptrace with -B and -T. Wireshark knows how to handle this file too.
pcap format *does* handle sliced frames, as each frame has a "captured length" and "length" field; if the frame is sliced, the "captured length" is the number of bytes of data after the slicing, and the "length" is the number of bytes of data before the slicing.
As, with -T, pcap, rather than iptrace, format is used, for iptrace with -B and -T, it doesn't matter whether iptrace format handles sliced frames well, as iptrace format isn't being used. That's why it works with Wireshark.
The problem is with -B and without -T - either
1) iptrace format has a place to put the "length" (before slicing), and Wireshark doesn't yet know where it is
or
2) iptrace format has no place to put the "length" (before slicing).
If the former, there's a Wireshark deficiency. If the latter, it's an inherent problem with the iptrace format, and *any* program that reads it runs the risk of reporting odd results with sliced packets; fixing it might require an "iptrace 3.0" format, with iptrace changed to read and write that format.