ARCnet¶
Note
See also arcnet-hardware.txt in this directory for jumper-settingand cabling information if you’re like many of us and didn’t happen to get amanual with your ARCnet card.
Since no one seems to listen to me otherwise, perhaps a poem will get yourattention:
This driver's getting fat and beefy,But my cat is still named Fifi.
Hmm, I think I’m allowed to call that a poem, even though it’s only twolines. Hey, I’m in Computer Science, not English. Give me a break.
The point is: I REALLY REALLY REALLY REALLY REALLY want to hear from you ifyou test this and get it working. Or if you don’t. Or anything.
ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this wasnice, but after that even FEWER people started writing to me because theydidn’t even have to install the patch. <sigh>
Come on, be a sport! Send me a success report!
(hey, that was even better than my original poem… this is getting bad!)
Warning
If you don’t e-mail me about your success/failure soon, I may be forced tostart SINGING. And we don’t want that, do we?
(You know, it might be argued that I’m pushing this point a little too much.If you think so, why not flame me in a quick little e-mail? Please alsoinclude the type of card(s) you’re using, software, size of network, andwhether it’s working or not.)
My e-mail address is:apenwarr@worldvisions.ca
These are the ARCnet drivers for Linux.
This new release (2.91) has been put together by David Woodhouse<dwmw2@infradead.org>, in an attempt to tidy up the driver after adding supportfor yet another chipset. Now the generic support has been separated from theindividual chipset drivers, and the source files aren’t quite so packed with#ifdefs! I’ve changed this file a bit, but kept it in the first person fromAvery, because I didn’t want to completely rewrite it.
The previous release resulted from many months of on-and-off effort from me(Avery Pennarun), many bug reports/fixes and suggestions from others, and inparticular a lot of input and coding from Tomasz Motylewski. Starting withARCnet 2.10 ALPHA, Tomasz’s all-new-and-improved RFC1051 support has beenincluded and seems to be working fine!
Where do I discuss these drivers?¶
Tomasz has been so kind as to set up a new and improved mailing list.Subscribe by sending a message with the BODY “subscribe linux-arcnet YOURREAL NAME” tolistserv@tichy.ch.uj.edu.pl. Then, to submit messages to thelist, mail tolinux-arcnet@tichy.ch.uj.edu.pl.
There are archives of the mailing list at:
The people onlinux-net@vger.kernel.org (now defunct, replaced bynetdev@vger.kernel.org) have also been known to be very helpful, especiallywhen we’re talking about ALPHA Linux kernels that may or may not work rightin the first place.
Other Drivers and Info¶
You can try my ARCNET page on the World Wide Web at:
Also, SMC (one of the companies that makes ARCnet cards) has a WWW site youmight be interested in, which includes several drivers for various cardsincluding ARCnet. Try:
Performance Technologies makes various network software that supportsARCnet:
http://www.perftech.com/ or ftp to ftp.perftech.com.
Novell makes a networking stack for DOS which includes ARCnet drivers. TryFTPing to ftp.novell.com.
You can get the Crynwr packet driver collection (including arcether.com, theone you’ll want to use with ARCnet cards) fromoak.oakland.edu:/simtel/msdos/pktdrvr. It won’t work perfectly on a 386+without patches, though, and also doesn’t like several cards. Fixedversions are available on my WWW page, or via e-mail if you don’t have WWWaccess.
Installing the Driver¶
All you will need to do in order to install the driver is:
make config (be sure to choose ARCnet in the network devices and at least one chipset driver.)make cleanmake zImage
If you obtained this ARCnet package as an upgrade to the ARCnet driver inyour current kernel, you will need to first copy arcnet.c over the one inthe linux/drivers/net directory.
You will know the driver is installed properly if you get some ARCnetmessages when you reboot into the new Linux kernel.
There are four chipset options:
- Standard ARCnet COM90xx chipset.
This is the normal ARCnet card, which you’ve probably got. This is the onlychipset driver which will autoprobe if not told where the card is.It following options on the command line:
com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
If you load the chipset support as a module, the options are:
io=<io> irq=<irq> shmem=<shmem> device=<name>
To disable the autoprobe, just specify “com90xx=” on the kernel command line.To specify the name alone, but allow autoprobe, just put “com90xx=<name>”
- ARCnet COM20020 chipset.
This is the new chipset from SMC with support for promiscuous mode (packetsniffing), extra diagnostic information, etc. Unfortunately, there is nosensible method of autoprobing for these cards. You must specify the I/Oaddress on the kernel command line.
The command line options are:
com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
If you load the chipset support as a module, the options are:
io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>timeout=<timeout> device=<name>
The COM20020 chipset allows you to set the node ID in software, overriding thedefault which is still set in DIP switches on the card. If you don’t have theCOM20020 data sheets, and you don’t know what the other three options referto, then they won’t interest you - forget them.
- ARCnet COM90xx chipset in IO-mapped mode.
This will also work with the normal ARCnet cards, but doesn’t use the sharedmemory. It performs less well than the above driver, but is provided in caseyou have a card which doesn’t support shared memory, or (strangely) in caseyou have so many ARCnet cards in your machine that you run out of shmem slots.If you don’t give the IO address on the kernel command line, then the driverwill not find the card.
The command line options are:
com90io=<io>[,<irq>][,<name>]
- If you load the chipset support as a module, the options are:
io=<io> irq=<irq> device=<name>
- ARCnet RIM I cards.
These are COM90xx chips which are _completely_ memory mapped. The support forthese is not tested. If you have one, please mail the author with a successreport. All options must be specified, except the device name.Command line options:
arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
If you load the chipset support as a module, the options are:
shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
Loadable Module Support¶
Configure and rebuild Linux. When asked, answer ‘m’ to “Generic ARCnetsupport” and to support for your ARCnet chipset if you want to use theloadable module. You can also say ‘y’ to “Generic ARCnet support” and ‘m’to the chipset support if you wish.
make configmake cleanmake zImagemake modules
If you’re using a loadable module, you need to use insmod to load it, andyou can specify various characteristics of your card on the commandline. (In recent versions of the driver, autoprobing is much more reliableand works as a module, so most of this is now unnecessary.)
For example:
cd /usr/src/linux/modulesinsmod arcnet.oinsmod com90xx.oinsmod com20020.o io=0x2e0 device=eth1
Using the Driver¶
If you build your kernel with ARCnet COM90xx support included, it shouldprobe for your card automatically when you boot. If you use a differentchipset driver complied into the kernel, you must give the necessary optionson the kernel command line, as detailed above.
Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should beavailable where you picked up this driver. Think of your ARCnet as asouped-up (or down, as the case may be) Ethernet card.
By the way, be sure to change all references from “eth0” to “arc0” in theHOWTOs. Remember that ARCnet isn’t a “true” Ethernet, and the device nameis DIFFERENT.
Multiple Cards in One Computer¶
Linux has pretty good support for this now, but since I’ve been busy, theARCnet driver has somewhat suffered in this respect. COM90xx support, ifcompiled into the kernel, will (try to) autodetect all the installed cards.
If you have other cards, with support compiled into the kernel, then you canjust repeat the options on the kernel command line, e.g.:
LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
If you have the chipset support built as a loadable module, then you need todo something like this:
insmod -o arc0 com90xxinsmod -o arc1 com20020 io=0x2e0insmod -o arc2 com90xx
The ARCnet drivers will now sort out their names automatically.
How do I get it to work with…?¶
- NFS:
Should be fine linux->linux, just pretend you’re using Ethernet cards.oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients. Thereis also a DOS-based NFS server called SOSS. It doesn’t multitaskquite the way Linux does (actually, it doesn’t multitask AT ALL) butyou never know what you might need.
With AmiTCP (and possibly others), you may need to set the followingoptions in your Amiga nfstab: MD 1024 MR 1024 MW 1024(Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>for this.)
Probably these refer to maximum NFS data/read/write block sizes. Idon’t know why the defaults on the Amiga didn’t work; write to me ifyou know more.
- DOS:
- If you’re using the freeware arcether.com, you might want to installthe driver patch from my web page. It helps with PC/TCP, and alsocan get arcether to load if it timed out too quickly duringinitialization. In fact, if you use it on a 386+ you REALLY needthe patch, really.
- Windows:
- See DOS :) Trumpet Winsock works fine with either the Novell orArcether client, assuming you remember to load winpkt of course.
- LAN Manager and Windows for Workgroups:
These programs use protocols thatare incompatible with the Internet standard. They try to pretendthe cards are Ethernet, and confuse everyone else on the network.
However, v2.00 and higher of the Linux ARCnet driver supports thisprotocol via the ‘arc0e’ device. See the section on “MultiprotocolSupport” for more information.
Using the freeware Samba server and clients for Linux, you can nowinterface quite nicely with TCP/IP-based WfWg or Lan Managernetworks.
- Windows 95:
- Tools are included with Win95 that let you use either the LANMANstyle network drivers (NDIS) or Novell drivers (ODI) to handle yourARCnet packets. If you use ODI, you’ll need to use the ‘arc0’device with Linux. If you use NDIS, then try the ‘arc0e’ device.See the “Multiprotocol Support” section below if you need arc0e,you’re completely insane, and/or you need to build some kind ofhybrid network that uses both encapsulation types.
- OS/2:
I’ve been told it works under Warp Connect with an ARCnet driver fromSMC. You need to use the ‘arc0e’ interface for this. If you getthe SMC driver to work with the TCP/IP stuff included in the“normal” Warp Bonus Pack, let me know.
ftp.microsoft.com also has a freeware “Lan Manager for OS/2” clientwhich should use the same protocol as WfWg does. I had no luckinstalling it under Warp, however. Please mail me with any results.
- NetBSD/AmiTCP:
- These use an old version of the Internet standard ARCnetprotocol (RFC1051) which is compatible with the Linux driver v2.10ALPHA and above using the arc0s device. (See “Multiprotocol ARCnet”below.) ** Newer versions of NetBSD apparently support RFC1201.
Using Multiprotocol ARCnet¶
The ARCnet driver v2.10 ALPHA supports three protocols, each on its own“virtual network device”:
arc0 RFC1201 protocol, the official Internet standard which justhappens to be 100% compatible with Novell’s TRXNET driver.Version 1.00 of the ARCnet driver supported _only_ thisprotocol. arc0 is the fastest of the three protocols (forwhatever reason), and allows larger packets to be usedbecause it supports RFC1201 “packet splitting” operations.Unless you have a specific need to use a different protocol,I strongly suggest that you stick with this one. arc0e “Ethernet-Encapsulation” which sends packets over ARCnetthat are actually a lot like Ethernet packets, including the6-byte hardware addresses. This protocol is compatible withMicrosoft’s NDIS ARCnet driver, like the one in WfWg andLANMAN. Because the MTU of 493 is actually smaller than theone “required” by TCP/IP (576), there is a chance that somenetwork operations will not function properly. The LinuxTCP/IP layer can compensate in most cases, however, byautomatically fragmenting the TCP/IP packets to make themfit. arc0e also works slightly more slowly than arc0, forreasons yet to be determined. (Probably it’s the smallerMTU that does it.) arc0s The “[s]imple” RFC1051 protocol is the “previous” Internetstandard that is completely incompatible with the newstandard. Some software today, however, continues tosupport the old standard (and only the old standard)including NetBSD and AmiTCP. RFC1051 also does not supportRFC1201’s packet splitting, and the MTU of 507 is stillsmaller than the Internet “requirement,” so it’s quitepossible that you may run into problems. It’s also slowerthan RFC1201 by about 25%, for the same reason as arc0e.
The arc0s support was contributed by Tomasz Motylewskiand modified somewhat by me. Bugs are probably my fault.
You can choose not to compile arc0e and arc0s into the driver if you want -this will save you a bit of memory and avoid confusion when eg. trying touse the “NFS-root” stuff in recent Linux kernels.
The arc0e and arc0s devices are created automatically when you firstifconfig the arc0 device. To actually use them, though, you need to alsoifconfig the other virtual devices you need. There are a number of ways youcan set up your network then:
Single Protocol.
This is the simplest way to configure your network: use just one of thetwo available protocols. As mentioned above, it’s a good idea to useonly arc0 unless you have a good reason (like some other software, ie.WfWg, that only works with arc0e).
If you need only arc0, then the following commands should get you going:
ifconfig arc0 MY.IP.ADD.RESSroute add MY.IP.ADD.RESS arc0route add -net SUB.NET.ADD.RESS arc0[add other local routes here]
If you need arc0e (and only arc0e), it’s a little different:
ifconfig arc0 MY.IP.ADD.RESSifconfig arc0e MY.IP.ADD.RESSroute add MY.IP.ADD.RESS arc0eroute add -net SUB.NET.ADD.RESS arc0e
arc0s works much the same way as arc0e.
More than one protocol on the same wire.
Now things start getting confusing. To even try it, you may need to bepartly crazy. Here’s whatI did. :) Note that I don’t include arc0s inmy home network; I don’t have any NetBSD or AmiTCP computers, so I onlyuse arc0s during limited testing.
I have three computers on my home network; two Linux boxes (which preferRFC1201 protocol, for reasons listed above), and one XT that can’t runLinux but runs the free Microsoft LANMAN Client instead.
Worse, one of the Linux computers (freedom) also has a modem and acts asa router to my Internet provider. The other Linux box (insight) also hasits own IP address and needs to use freedom as its default gateway. TheXT (patience), however, does not have its own Internet IP address and soI assigned it one on a “private subnet” (as defined by RFC1597).
To start with, take a simple network with just insight and freedom.Insight needs to:
- talk to freedom via RFC1201 (arc0) protocol, because I like itmore and it’s faster.
- use freedom as its Internet gateway.
That’s pretty easy to do. Set up insight like this:
ifconfig arc0 insightroute add insight arc0route add freedom arc0 /* I would use the subnet here (like I said to in "single protocol" above), but the rest of the subnet unfortunately lies across the PPP link on freedom, which confuses things. */route add default gw freedom
And freedom gets configured like so:
ifconfig arc0 freedomroute add freedom arc0route add insight arc0/* and default gateway is configured by pppd */
Great, now insight talks to freedom directly on arc0, and sends packetsto the Internet through freedom. If you didn’t know how to do the above,you should probably stop reading this section now because it only getsworse.
Now, how do I add patience into the network? It will be using LANMANClient, which means I need the arc0e device. It needs to be able to talkto both insight and freedom, and also use freedom as a gateway to theInternet. (Recall that patience has a “private IP address” which won’twork on the Internet; that’s okay, I configured Linux IP masquerading onfreedom for this subnet).
So patience (necessarily; I don’t have another IP number from myprovider) has an IP address on a different subnet than freedom andinsight, but needs to use freedom as an Internet gateway. Worse, mostDOS networking programs, including LANMAN, have braindead networkingschemes that rely completely on the netmask and a ‘default gateway’ todetermine how to route packets. This means that to get to freedom orinsight, patience WILL send through its default gateway, regardless ofthe fact that both freedom and insight (courtesy of the arc0e device)could understand a direct transmission.
I compensate by giving freedom an extra IP address - aliased ‘gatekeeper’ -that is on my private subnet, the same subnet that patience is on. Ithen define gatekeeper to be the default gateway for patience.
To configure freedom (in addition to the commands above):
ifconfig arc0e gatekeeperroute add gatekeeper arc0eroute add patience arc0e
This way, freedom will send all packets for patience through arc0e,giving its IP address as gatekeeper (on the private subnet). When ittalks to insight or the Internet, it will use its “freedom” Internet IPaddress.
You will notice that we haven’t configured the arc0e device on insight.This would work, but is not really necessary, and would require me toassign insight another special IP number from my private subnet. Sinceboth insight and patience are using freedom as their default gateway, thetwo can already talk to each other.
It’s quite fortunate that I set things up like this the first time (coughcough) because it’s really handy when I boot insight into DOS. There, itruns the Novell ODI protocol stack, which only works with RFC1201 ARCnet.In this mode it would be impossible for insight to communicate directlywith patience, since the Novell stack is incompatible with Microsoft’sEthernet-Encap. Without changing any settings on freedom or patience, Isimply set freedom as the default gateway for insight (now in DOS,remember) and all the forwarding happens “automagically” between the twohosts that would normally not be able to communicate at all.
For those who like diagrams, I have created two “virtual subnets” on thesame physical ARCnet wire. You can picture it like this:
[RFC1201 NETWORK] [ETHER-ENCAP NETWORK](registered Internet subnet) (RFC1597 private subnet) (IP Masquerade) /---------------\ * /---------------\ | | * | | | +-Freedom-*-Gatekeeper-+ | | | | * | | \-------+-------/ | * \-------+-------/ | | | Insight | Patience (Internet)
It works: what now?¶
Send mail describing your setup, preferably including driver version, kernelversion, ARCnet card model, CPU type, number of systems on your network, andlist of software in use to me at the following address:
I do send (sometimes automated) replies to all messages I receive. My emailcan be weird (and also usually gets forwarded all over the place along theway to me), so if you don’t get a reply within a reasonable time, pleaseresend.
It doesn’t work: what now?¶
Do the same as above, but also include the output of the ifconfig and routecommands, as well as any pertinent log entries (ie. anything that startswith “arcnet:” and has shown up since the last reboot) in your mail.
If you want to try fixing it yourself (I strongly recommend that you mail meabout the problem first, since it might already have been solved) you maywant to try some of the debug levels available. For heavy testing onD_DURING or more, it would be a REALLY good idea to kill your klogd daemonfirst! D_DURING displays 4-5 lines for each packet sent or received. D_TX,D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,which is obviously quite big.
Starting with v2.40 ALPHA, the autoprobe routines have changedsignificantly. In particular, they won’t tell you why the card was notfound unless you turn on the D_INIT_REASONS debugging flag.
Once the driver is running, you can run the arcdump shell script (availablefrom me or in the full ARCnet package, if you have it) as root to list thecontents of the arcnet buffers at any time. To make any sense at all out ofthis, you should grab the pertinent RFCs. (some are listed near the top ofarcnet.c). arcdump assumes your card is at 0xD0000. If it isn’t, edit thescript.
Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending.Ping-pong buffers are implemented both ways.
If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,the buffers are cleared to a constant value of 0x42 every time the card isreset (which should only happen when you do an ifconfig up, or when Linuxdecides that the driver is broken). During a transmit, unused parts of thebuffer will be cleared to 0x42 as well. This is to make it easier to figureout which bytes are being used by a packet.
You can change the debug level without recompiling the kernel by typing:
ifconfig arc0 down metric 1xxx/etc/rc.d/rc.inet1
where “xxx” is the debug level you want. For example, “metric 1015” would putyou at debug level 15. Debug level 7 is currently the default.
Note that the debug level is (starting with v1.90 ALPHA) a binarycombination of different debug flags; so debug level 7 is really 1+2+4 orD_NORMAL+D_EXTRA+D_INIT. To include D_DURING, you would add 16 to this,resulting in debug level 23.
If you don’t understand that, you probably don’t want to know anyway.E-mail me about your problem.
I want to send money: what now?¶
Go take a nap or something. You’ll feel better in the morning.