Will Barker wrote:
Thanks Guy for your very quick and informative response - comments below.
1) Inline with the realtime capture support currently offered on Windows
by other device types,
"Realtime capture support" in what sense? "Update list of packets in
real time"?
I just mean capturing/displaying in realtime as opposed to reading from a
file (of a previously recorded session). We've supported the latter for a
while now by enabling our captured data to be saved in libpcap format by our
apps.
That should work without packet.dll changes.
I'm not sure that there is an absolute *need* but I found myself going down
that path since the normal win32 cases seem to lead you that way e.g. to
fad-win32: pcap_findalldevs -> PacketGetAdapterNames etc.
That's not a modification of packet.dll; it's just using
PacketGetAdapterNames() as the call on Windows, just as you use various
ioctls or getifaddrs() on various UN*X systems. packet.dll is to
WinPcap as the various low-level platform-specific capture mechanisms
are to various UN*X systems.
I was also
influenced I think by the fact that other 3rd party support had been added
that way (e.g. DAG, AIRPCAP) but perhaps it was just done that way in order
to leverage already existing support within packet.dll for those devices? -
which could be useful independent on any wpcap/wireshark-specific usage?)
...or it might date back to a time before libpcap/WinPcap was set up to
support add-on support for devices not using the standard capture mechanism.
OK - will do. However, that was just intended as an example. I was hoping
that there would be some way of decoupling DLT and WTAP values
No. WTAP values are internal values for Wireshark; capture files use
DLT_ values (well, actually, they use LINKTYPE_ values as defined in
savefile.c, but almost all of them are equal to the matching DLT_
values; the split is due to some cases where different platforms define
the same DLT_ value differently - that can work for programs for a
particular platform, but *doesn't* work for capture files that are
supposed to be readable on *all* platforms).
so that it
wasn't necessary to add 1) a DLT value and b) a mapping to a WTAP_ENCAP
value in pcap_to_wtap_map in order to enable a pcap device to supply frames
of any particular WTAP_ENCAP value for decode.
It's intentional that they're separate. Libpcap/WinPcap, and the
libpcap file format, are intended for use by multiple applications, so
they're defined independently of Wireshark. Wireshark supports capture
file formats other than libpcap, and those formats have link-layer
header types not supported by libpcap, so it has its own set of
link-layer type values.
See, for example, the way DLT_MTP2_WITH_PHDR (value 139; search for
WTAP_ENCAP_MTP2_WITH_PHDR in wiretap/libpcap.c) is handled.
Yes there does seem to be potential for doing the same with
WTAP_ENCAP_PPP_WITH_PHDR for instance?
Yes, but you'd need to use a DLT_ value that maps to
WTAP_ENCAP_PPP_WITH_PHDR. There currently isn't one.
What are the capture attributes you need?
The kind of thing I'm referring to here is configuration for our card, for
example,
a) selecting the type of line encoding for sync lines e.g. NRZ, NRZI, FM0
etc.
b) selecting the line interface type e.g. V.24, X.21, V.35 etc.
c) for monitoring async lines, selecting the rate, # of stop bits, parity
etc.
Those sound as if they might be useful for other serial-port monitoring
hardware; I don't know whether, for example, the API that Endace
supplies for DAG cards supports setting those values, but, if it does,
libpcap/WinPcap calls to set those properties could be used by DAG cards
as well.
For now, you'd have to add your own APIs for that to WinPcap, and
Wireshark would have to be modified to use it. You'd also want to have
an API that can be used to determine whether a given device supports
those APIs, so that you don't offer the ability to select a line
interface type on a 802.11 network. :-)
(In the longer term, I'd like to have libpcap/WinPcap support an
attribute-value-pair mechanism for device properties, so that
1) an application can query a device to find out what properties it
supports;
2) that application can then set those properties either at open time
or, if possible and appropriate, while the capture is in progress (e.g.,
the channel number for an 802.11 adapter);
3) new properties can be added without having to add new API functions.)