On Jul 10, 2007, at 1:42 PM, Fulko.Hew@xxxxxxxxx wrote:
I'm trying to figure out how to format (or where to place the data)
in the pcap buffer when capturing my WAN protocols.
I've built a system that will capture the data and feed it via pcap
to wireshark, and I've got it working for Ethernet data and for
frame relay data, but I'm having trouble dealing with getting the
proprietary data into wireshark intact so that I can later write a
disector.
(I'm going to test everything out before submitting my requests for
a set of DLT_ mumbers for these protocols. In the mean time, I've
just taken the next few currently un-assigned ones while I work on
my code).
The trouble is that I don't know what values to put into:
off_linktype, off_nl and off_nl_nosnap for my DLT cases. (And I
think thats where my problem lies.)
Given that off_linktype, off_nl, and off_nl_nosnap are used *only* by
the BPF code generator when it generates code for a capture filter, I
really really really don't think that's where your problem lies,
unless your problem is a problem with capture filters, and from what
you say, it's *not* a problem with capture filters (as capture filters
only control which packets are captured, they don't control the format
of the packet).
Right now, the first thing in each received buffer is the typical 16
bytes of: timestamp_sec, timestamp_usec, capture_len, pkt_len, which
is followed by 'n' bytes of my protocol's data.
I.e., each received buffer is a "struct pcap_pkthdr", followed by the
packet data.
Presumably, if you've implemented a libpcap module for this (if that's
what "capture the data and feed it via pcap" means), then, presumably,
your "read_op" routine is calling the callback routine with the second
argument pointing to the 16-byte "struct pcap_pkthdr" header and the
third argument pointing to the protocol data.
When Wireshark goes to display it, the Protocol column says
'unknown', which I can understand, because I don't have any
disectors for that DLT (WTYP_ENCAP) type yet.
The Info column says WTAP_ENCAP = 94. (I don't see where it gets
the value of '94' from.)
Presumably, in order for your file to be read *at all* by Wireshark,
you modified Wireshark so that the pcap_to_wtap_map[] array in wiretap/
libpcap.c maps the relevant "currently un-assigned" DLT_ values you're
using (note that the "the next few currently un-assigned" values start
at 196; *ALL* values from 100 through 196 are assigned) to some
WTAP_ENCAP value. If it maps it to 94, then that's where the 94 comes
from - but 94 is, in the top-of-tree version of Wireshark,
WTAP_ENCAP_NETTL_RAW_TELNET, so you probably don't want to map
anything to that.
The summary pane (for the first message) says:
Frame 1 had (6 bytes on wire, 6 bytes captured)
Data (6 bytes)
and the (related) detail pane says:
0000 7f 56 ae 93 46 7e
Then the capture file that Wireshark is reading, if it's a libpcap-
format file, must have had a capture_len value of 6 and a len value of
6.
Where did that file come from? Did you modify libpcap so that it can
capture from your device, and did you use Wireshark to capture the
traffic, or do you have some other program capturing from your device
and writing out a libpcap-format file?
