The second type of module used with Linux-ARCnet is an encapsulation driver. These manage the formatting of packets on the ARCnet network.
For historical reasons, there are several different ways to arrange TCP/IP packets (for example) on an ARCnet network. In fact, there are even two incompatible internet standards about it: RFC1051 and RFC1201.
Nowadays, almost everyone who wants to do TCP/IP over ARCnet will use RFC1201. Unfortunately, that wasn't always true in the past, and some people still need to talk to computers with older drivers.
Also, most new ARCnet installations nowadays are on industrial fieldbus networks, where engineers are taking advantage of ARCnet's reliability to control various types of embedded systems. These often don't use TCP/IP, so version of the Linux ARCnet driver starting with 3.80 let you skip encapsulation completely and transmit/receive raw packets directly on the network.
Of course, it's no fun (and often unrealistic) if everyone speaks the same protocol, so the Linux driver will happily let you use a different packet encapsulation for talking to each different host on your network. That means you can have some hosts using RFC1051 and some using RFC1201, and although they can't talk to each other, they can talk to your Linux box. If the Linux box is configured correctly, it can even route packets so that the incompatible hosts can talk to each other.
In older versions of the Linux ARCnet driver, we configured the protocols by using `arc0' for RFC1201, and having optional `arc0s' and `arc0e' devices to do RFC1051 and ethernet-encap. Then, you could configure IP or IPX protocols and routing on top of those.
What I always wanted to do instead was have the driver select the right encapsulation automatically for each host on the network, to make it transparent. That's what we do now, in 3.80 and higher. You load a module for each encapsulation you support, and the driver automatically selects the right one depending on the packets received from each host. Only the `arc0' device exists now.
If autodetection scares you and you don't think it'll work, then you should only load one of the following encapsulation drivers. Then that driver will be used to talk to everyone on your network.
This is the current Internet standard. If you want to use TCP/IP with your ARCnet card, this is probably what you want.
It was the only encapsulation supported by Linux-ARCnet 1.xx.
RFC1051 is the older Internet standard. It has a packet size (MTU) limitation of 507 bytes, which makes it slightly less efficient than RFC1201. Also, some kinds of UDP software can't deal with the small packet size, and simply won't work.
But if you have to talk to other software using RFC1051 (like old versions of NetBSD and AmiTCP), this is the way to do it.
I suspect that this encapsulation type was invented accidentally by a lazy programmer who was so thrilled when his ARCnet driver worked that he didn't bother to check whether it complied with any standards.
It works like this: take an ethernet packet that says what you want to say, limit its size to something that will fit in an ARCnet packet, and put an ARCnet header on the front. This works fine, but wastes lots of bytes with extra ethernet headers (like 12 bytes of source/destination address).
Older versions of Linux-ARCnet supported this encapsulation, but the support hasn't yet been updated to ARCnet 3.90, because I haven't had time. Any volunteers?
Raw mode is no encapsulation at all - if you send a packet, it gets sent without any extra headers whatsoever. If you receive a packet, none of the headers get removed before sending the packet on to whomever will process it.
I guess it would be possible to do TCP/IP this way, except there needs to be a way to tell the difference between ARP and IP packets. Maybe it would work if you disabled ARP. Anyway, it's not a good idea.
The idea of raw mode is to let you implement any encapsulation you want in a user-space program. For details about how to do this, see Using the raw mode encap from userspace.
Often, when you're using arc-rawmode, you won't want to load any other encapsulation drivers, since they might just get in the way. This isn't a necessity, though, and it's perfectly possible to combine raw packets and RFC1201 or RFC1051 packets on the same network.