Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: [Ethereal-dev] Adding the ability to analyze a non-IP non-Ethernet protocol

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "S. Tyler McHenry" <smchenry@xxxxxxx>
Date: Wed, 1 Jun 2005 20:47:15 -0700
I have new network layer protocol that I wish to analyze using Ethereal. In 
addition to not being IP, it also runs over a new type of physical layer (a 
very simple radio).

At the moment, this radio device is attached to my computer through a serial 
cable. I have written a device driver similar to SLIP which presents to Linux 
a network interface linked to the serial port. I can successfully read 
packets off of the radio using this driver (it can be read-only for now, 
since I only want to sniff traffic).

From the driver, I get packets that look like this:

------- Physical (Radio) Layer --------
[BEGIN byte]
[Packet Length]
[CRC-16]*
------- Network Layer -----------------
[Type]
[To Address]
[From Address]
[Other fields not important to this issue]
------- Higher Layers -----------------
[Data]


* In actuality the CRC-16 appears at the end of the packet, but it's part of 
the physical layer logically.

And now I have a problem. I have no idea what it the best way to go about 
getting this into Ethereal. If the driver sets the arptype to ARPHRD_SLIP the 
packets are captured and show up as "Raw IP", but I don't have the option to 
"Decode As" using the decoder I wrote for the network layer protocol, the 
entire "Decode As" menu option is grey'ed-out.

Is there any way I can add the ability to replace "Raw IP" with "Raw 
MyNetworkProtocol" and run the appropriate dissector? It isn't a problem to 
have the driver strip the physical layer data if necessary.

I was thinking maybe I could fake an Ethernet header or something, but my 
physical layer has no concept of addressing and my network layer addresses 
are just uint16's, with no correspondence to Ethernet or IP-style addresses.

At some point I might also wish to add dissectors for higher-level protocols 
which will run on top of this new network-layer protocol.

I'd like to know what the simplest approach to this is - most specifically if 
I'm going to be able to avoid adding a whole new ARPHRD type and making 
changes to libpcap and wiretap.

Thanks a whole lot for any help.

-- 
S. Tyler McHenry 

PGP Public Key:
http://www.nerdland.net/~tyler/info/pgp-public.txt
 

Attachment: pgpMluBwfVY0k.pgp
Description: PGP signature