On Thu, Oct 17, 2002 at 07:44:26AM -0500, Peter Fales wrote:
> I asked yesterday if there was any interest in my patches for supporting
> arcnet in ethereal.
Either you didn't ask ethereal-dev or ethereal-users or that mail is
still queued up somewhere, as I've never seen it.
> 1) I had to make some changes to libpcap to include arcnet support (on
> linux, at least).
That's because you have an old version of libpcap. The current CVS
version of libpcap includes ARCNET support; download that, test it out,
and send any fixes required to patches@xxxxxxxxxxx or submit them via
SourceForge.
Libpcap and tcpdump are being developed by The Tcpdump Group (I guess
that's what we in that group call ourselves); see
http://www.tcpdump.org/
The current CVS version can be downloaded from the links under "Current
Tar files" on that page; libpcap 0.7/tcpdump 3.7 also include ARCNET
support, I think - I forget whether it was in there in 0.6/3.6 or not -
but you might as well work with the current CVS version.
> 2) Since arcnet basically does an encapsulation of ethernet frames,
An "Ethernet frame" begins with a 6-byte destination address, followed
by a 6-byte source address, followed by a 2-byte type/length field,
followed by payload which is a packet for the protocol being sent over
Ethernet; I think by "ethernet frames" you're referring to the payload
in question, not to an actual Ethernet frame.
> I wanted to use the existing ethernet dissectors such as
>
> dissect_arp()
> dissect_ip()
> dissect_ipx()
Those aren't Ethernet dissectors, those are ARP, IP, and IPX dissectors,
(just as the stuff inside an ARCNET frame isn't an Ethernet frame); they
are called, directly or indirectly, from many dissectors, including the
PPP, Frame Relay, 802.2 LLC, etc. dissectors.
> But, I had to change these definitions from "static void" to just "void"
> so that I could call them from my own files (e.g. packet-arcnet.c)
>
> I didn't see any precedent for that, so I'm wondering if there is a
> different/better way to do invoke these dissectors.
Yes, there is.
The way the Ethernet, PPP, etc. dissectors work is that they define a
"dissector table" (which is currently not documented in the
"README.developer" file, unfortunately). A "dissector table" associates
numbers with handles for dissectors, and the dissector using the
dissector table uses a routine to look up a protocol type field's value
in that table and, if it finds an entry, call the dissector whose handle
is in that entry.
For Ethernet protocol types, which are used by several encapsulation
schemes (Ethernet and 802.2 LLC with SNAP, for example), there's a
file "packet-ethertype.c" that handles the Ethernet type dissector
table.
For ARCNET, you'd define a table with a name such as
"arcnet.protocol_id", with a call like
arcnet_dissector_table = register_dissector_table("arcnet.protocol_id",
"ARCNET Protocol ID", FT_UINT8, BASE_HEX);
In the ARCNET dissector, when it's ready to call a subdissector, it'd do
something such as
if (!dissector_try_port(arcnet_dissector_table, protId,
next_tvb, pinfo, tree)) {
if (check_col(pinfo->cinfo, COL_PROTOCOL)) {
col_add_fstr(pinfo->cinfo, COL_PROTOCOL, "0x%04x",
system_code);
call_dissector(data_handle, next_tvb, pinfo, tree);
}
"data_handle" is a handle for the "dissect this as data" dissector,
which is the dissector of last resort, used here to dissect packets with
an ARCNET protocol ID for which there's no other dissector. In
"proto_reg_handoff_arcnet()", you'd do
data_handle = find_dissector("data");
to get that handle.
In the IP dissector, you'd add to "proto_reg_handoff_ip()" the line
dissector_add("arcnet.protocol_id", 0xd4, ip_handle);
and you'd do similar things to the ARP and IPX dissectors.
Or, even better, you'd define a new header file "arcnet_proto_ids.h",
put #defines for the ARCNET protocol IDs, and use those #defines in the
IP, ARP, IPX, and ARCNET dissectors rather than using the raw hex
numbers.
