The difference there isn't the file type, it's the capture mechanism what the iptrace man page says is I want to investigate this a little more to make sure the three statements above are correct.
It seems probable that this is an AIX bug. Wireshark knows how to handle this file too. B uses the bpf filter from tcpdump but formats the output as an iptrace file. Wireshark knows how to use those file just fine. I can do that but wanted to point out that there are three ways to run iptrace. We may mark it as "WONTFIX" if there's no "on the wire" packet length we could find otherwise, if we find it, we'll fix it. Indicate in the bug what the "on-the-wire" packet length(s) for the packet(s) in question should be one packet that was longer, on the wire, than the snapshot length should suffice. Attachments *can* be marked as private, so that, for example, capture files can be made readable only by Wireshark developers in the right group (Gerald, who's that?), but a quick test didn't show how to mark it as such *at the time you attach it*. File it against the product "Wireshark" and the component "Capture file support (libwiretap)". The best way would probably be to file a bug atĪsking for an enhancement to try to find out the "on-the-wire" packet length in iptrace packets, and attach the capture. This has happened more than once but may have used the same tools to capture the trace.īack on my original question: would you say that sense the Frame Length is bogus, wireshark is doing as well as expected? Let me ask the person who capture it how he did it and see where that takes us. "128 bytes on the wire (1024 bits), 128 bytes captured (1024 bits)" I noticed it but didn't put 2 and 2 together. The very first line essentially repeat these values too.
This was a 1500 byte packet with ethernet header (no vlan tag) - so probably 1514.
"sequence" referred to the TCP sequence number.įrame Length and Capture Length both say 128 bytes. However, I'm not seeing that in a tcpdump capture I did with a snapshot length of 128 in the Frame section of the 1500-byte IP datagram, what do the "Frame Length" and "Capture Length" fields say? "Frame Length" *should* say 1514 (I'm assuming from the "1500" that this is IP-over-Ethernet, with a 14-byte Ethernet header) if it's only 128, the file wasn't recorded correctly (or was recorded by software that, for some reason, wasn't able to get the packet's actual length). If by "sequence" you mean TCP sequence number, and the actual packet length as recorded in the file is more than 128 bytes, that would *absolutely* be a Wireshark bug - the captured length should be used in as few places as possible it should *only* be used to check whether particular packet data is actually available in the captured data, it should *never* be used as an indication of how much data there actually *is*. the next sequence is the current sequence plus the captured length, not the IP packet length. Wireshark is using the capture lengh of 128 instead of the real packet length. The IP header says that it is a 1500 byte packet. With a fairly simple ftp trace where we capture only the first 128 bytes of data, wireshark displays that it did not see the previous segment.
0 kommentar(er)
