Wireshark · Wireshark-dev: Re: [Wireshark-dev] capturing data from a propietary device

[Fulko.Hew@xxxxxxxxx]

wireshark-dev-bounces@xxxxxxxxxxxxx wrote on 07/10/2007 07:41:52 PM:

>
> 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).

OK.  And yes, one of the goals is to be able to use BPF.
But I think I'm beginning to agree with you, its not on the
'off_xxx' variables.  Nothing I do there seems to change
the symptoms.  But I'd still like to know what the appropriate
values would be.  -1 to disable or zero as the offset.

The reason I ask is because I intend to insert a few bytes
of 'level 1 signalling/status info that would have to be
skipped by the display routines.


> > 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.

Yes, and yes.

> > 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.

At the time I started this project (Jan) 94 was un-assigned,
(unfortunaltely I've had to set the project aside until now.)
And after I sent my email I then recognized the DLT to WTAP
mapping table in wireshark... so that explains that.

It still leaves my issue/question about the data length and
the offset that wireshark seems to see and use.


> > 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?

Yes. I have a modified libpcap that allows it to capture from my device
and I used Wireshark to initiate the capture.

No I am not currently using Wireshark to write/read a libpcap-format file.
I was going to verify that portion after getting the capture/display
part working.

So since the "struct pcap_pkthdr" specified a length of 0xb bytes and
the u_char *user pointer was pointing at the first byte of the data pkt
I'm at a loss to explain the 6 byte length wireshark sees.

You've convinced me that my changes to libpcap are probably correct
and I should now be focusing on wireshark and the data it sees coming
in for decode/display.


... snip ...

> > > Did you noticed
http://wiki.wireshark.org/Development/LibpcapFileFormat?
> >
> > Yes, I did, and I am in theory following it.
> > The difference is that the document refers to the 'file format' and
> > not the live stream, so the global header is not applicable.  This
> > information is (somehow) exchanged in a different manner via DLT_xxx
> > and WTAP_ENCAP_xxx
> >
> What do you mean by "the live stream"?

The data stream captured via my modified libpcap from the hardware as
passed
to Wireshark, as opposed to data read by Wireshark from a libpcap formatted
file.



This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.