Martin Warnes wrote:
I'm looking to write a wiretap module to provide support for the IBM
iSeries (OS/400) formatted packet trace and from looking at the trace
output (sample packet below) it appears that it should fit quite well as
the data appears to be fairly easy to extract, i.e packet number and
direction always at the same offset etc.
Looking at other modules in the wiretap diectory I think I can get my
head around most of it but there are a coupe of areas I'm not quite sure
of. Opening and basic sanity checking of the file to ensure that we are
dealing with an ASCII TCP trace and not a EBCDIC SNA trace seem fairly
straight forward,
Actually, Ethereal *can* dissect SDLC and SNA (if that's SNA-over-SDLC),
and it should be possible to translate EBCDIC to ASCII in a Wiretap
module, so you might want to look at handling those as well.
as does forward and backward packet traversal through
the capture file. The area I'm a little unsure of is the layout of the
psuedo header
The record in your mail appears to be an Ethernet packet; the
pseudo-header for Ethernet contains only one field, "fcs_len", which
should be:
0 if you *know* that the Ethernet adapter doesn't supply the FCS as
part of the packet data (either because it doesn't offer that option or
because the driver turns that option off) or the software removes it
before printing the frame data;
4 if you *know* the adapter supplies the FCS and the software includes
it in the frame data (regardless of whether the packet was "cut short"
during capture by a "slice length" or "snapshot length" specified as an
option to the trace software, along the lines of the snapshot length in
tcpdump/snoop/Ethereal) - note that frames sent *by* the machine doing
the trace probably won't have the FCS even if frames sent *to* that
machine have it;
-1 if the FCS might or might not be present depending on e.g. what
adapter is being used.
and capture data formating, which parts of the capture do
I need to extract
Ideally, all of it, starting with the Ethernet destination address.
and what is the best way to handle the fact that IP
header, TCP header and actual data are in different location?
Gather them together - along with the Ethernet header - and put them
back into a single continuous chunk of data, in binary form. In the
case of the frame in your message, that'd be
00 06 29 9C 14 AE 00 06 29 9C 14 FE 08 00 45 00
01 0E 38 8D 40 00 40 06 CC 07 0A 14 90 96 0A 14
90 97 17 76 8A 26 9E EF 1D 88 7F AE 99 3C 80 18
7F 88 D9 2B 00 00 01 01 08 0A 05 17 EC B0 05 16
75 B0 17 76 8A 26 9E EF 1D 88 7F AE 99 3C 80 18
7F 88 D9 2B 00 00 01 01 08 0A 05 17 EC B0 05 16
...
btw. I don't know if I mentioned this before but Ethereal is able to
handle SYSTCPDA formatted capture files from the IBM zSeries (OS/390)
without problems, might be worth mentioning this on the website.
The page at
ftp://ftp.software.ibm.com/software/network/commserver/downloads/systcpda.txt
says:
7) Add SNIFFER(TCPDUMP) to write packet trace records in TCPDUMP format.
which suggests that "SYSTCPDA formatted capture files" just means
"libpcap-formatted capture files", so we should just indicate that you
should write out the files in "TCPDUMP format" (which really means
"libpcap format" - there are a number of other programs that also read
that format) if you want to read them in Ethereal.
(If you could suggest to the OS/400 folks that they *also* look at
adopting libpcap format - perhaps mentioning that z/OS did so will help
- that might help. If they object that they need a link-layer type
value that libpcap format doesn't have, tell them to send mail to
tcpdump-workers@xxxxxxxxxxx asking for one.)