[Guy Harris <gharris@xxxxxxxxx>]

Philip Christian wrote:

> My thought is that I could right something that allows pcap to capture 
> and understand these bytes and that Ethereal could then display them on 
> a nice graphic interface.  I could nick bits of code from freediag if 
> necessary like the baud rate control stuff.
>
> Is this a good idea / stupid idea ?

It might be reasonable.

> Where should I look in the pcap / Ethereal code to start off ?

For libpcap, the first thing you'd need to do would be to get DLT_ 
values for all the link-layer protocols you'd need.  If ISO 9141 and 
14230 use the same link-layer protocol, they might be able to share a 
DLT_ value, unless the only way to know what protocols are running above 
the link layer is to know which link-layer protocol is being used, in 
which case you might want separate DLT_ values.

For the rest of the libpcap discussion, I'll assume you're working with 
the current top-of-tree CVS version of libpcap, and that this is on a 
UN*X platform.  You probably don't want to work with a version older 
than 0.8, even if whatever OS you're using happens to include libpcap - 
older versions are not as friendly towards adding support for devices 
other than standard network interfaces.

Then you'd probably add to the "pcap_open_live()" routine, for whatever 
platform or platforms this code should work, something such as a check 
for device names that look like serial port names and, if the check 
succeeds, a call to a routine to open the serial port.

See, for example, the "#ifdef HAVE_DAG_API" code in pcap-linux.c and 
pcap-bpf.c.

The serial port open routine would open the serial port device, set the 
baud rate and do anything else needed to open the device.  It'd allocate 
a pcap_t, set its "fd" member to the file descriptor for the serial 
device, set the "snapshot" member to the argument passed to the open 
routine, set the "linktype" member to one of the DLT_ values, and set 
the "selectable_fd" member to the same value as the "fd" member.  It 
should also set the "dlt_count" member to the number of DLT_ values to 
support, and allocate an array of "dlt_count" "u_int"s, assign it to the 
"dlt_list" member, and fill in that list with all the DLT_ values.

You'd then set the various _op fields to routines to handle the 
operations in question.  read_op is the routine that'd read packets from 
the device.  inject_op would be for sending packets; if you don't care 
about that, you'd set it to a routine that returns an error indication. 
   setfilter_op can probably just be set to install_bpf_program. 
set_datalink would just set the "linktype" member to the specified value 
if it's one of the values for OBD, otherwise it should return an error. 
getnonblock_op can probably be set to pcap_getnonblock_fd; 
setnonblock_op can probably be set to pcap_setnonblock_fd.  stats_op 
would be set to a routine that reports statistics.  close_op can 
probably be set to pcap_close_common.

If there's more than one DLT_ value, you definitely want a set_datalink 
routine, so that the user can select the appropriate link-layer type.

For Ethereal, you'd add support for those DLT_ values to 
wiretap/libpcap.c, which might mean adding one or more WTAP_ENCAP types 
to wtap.h and to the encap_table[] table in wiretap/wtap.c.  You'd then 
have to write a dissector or dissectors for the link-layer protocols or 
protocols and have them register themselves with the "wtap_encap" 
dissector table, with the appropriate WTAP_ENCAP values, by calling 
"dissector_add()".

See the README files in the doc directory, and the Ethereal developer's 
guide (linked to from http://wiki.ethereal.com/Development), for more 
information.