^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) ARCnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) See also arcnet-hardware.txt in this directory for jumper-setting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) and cabling information if you're like many of us and didn't happen to get a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) manual with your ARCnet card.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) Since no one seems to listen to me otherwise, perhaps a poem will get your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) attention::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) This driver's getting fat and beefy,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) But my cat is still named Fifi.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) Hmm, I think I'm allowed to call that a poem, even though it's only two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) lines. Hey, I'm in Computer Science, not English. Give me a break.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) The point is: I REALLY REALLY REALLY REALLY REALLY want to hear from you if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) you test this and get it working. Or if you don't. Or anything.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) nice, but after that even FEWER people started writing to me because they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) didn't even have to install the patch. <sigh>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Come on, be a sport! Send me a success report!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) (hey, that was even better than my original poem... this is getting bad!)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) .. warning::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) If you don't e-mail me about your success/failure soon, I may be forced to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) start SINGING. And we don't want that, do we?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) (You know, it might be argued that I'm pushing this point a little too much.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) If you think so, why not flame me in a quick little e-mail? Please also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) include the type of card(s) you're using, software, size of network, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) whether it's working or not.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) My e-mail address is: apenwarr@worldvisions.ca
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) These are the ARCnet drivers for Linux.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) This new release (2.91) has been put together by David Woodhouse
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) <dwmw2@infradead.org>, in an attempt to tidy up the driver after adding support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) for yet another chipset. Now the generic support has been separated from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) individual chipset drivers, and the source files aren't quite so packed with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) #ifdefs! I've changed this file a bit, but kept it in the first person from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) Avery, because I didn't want to completely rewrite it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) The previous release resulted from many months of on-and-off effort from me
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) (Avery Pennarun), many bug reports/fixes and suggestions from others, and in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) particular a lot of input and coding from Tomasz Motylewski. Starting with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) ARCnet 2.10 ALPHA, Tomasz's all-new-and-improved RFC1051 support has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) included and seems to be working fine!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Where do I discuss these drivers?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) Tomasz has been so kind as to set up a new and improved mailing list.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) Subscribe by sending a message with the BODY "subscribe linux-arcnet YOUR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) REAL NAME" to listserv@tichy.ch.uj.edu.pl. Then, to submit messages to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) There are archives of the mailing list at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) http://epistolary.org/mailman/listinfo.cgi/arcnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) The people on linux-net@vger.kernel.org (now defunct, replaced by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) netdev@vger.kernel.org) have also been known to be very helpful, especially
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) when we're talking about ALPHA Linux kernels that may or may not work right
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) in the first place.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) Other Drivers and Info
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) You can try my ARCNET page on the World Wide Web at:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) http://www.qis.net/~jschmitz/arcnet/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) might be interested in, which includes several drivers for various cards
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) including ARCnet. Try:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) http://www.smc.com/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) Performance Technologies makes various network software that supports
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) ARCnet:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) http://www.perftech.com/ or ftp to ftp.perftech.com.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Novell makes a networking stack for DOS which includes ARCnet drivers. Try
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) FTPing to ftp.novell.com.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) You can get the Crynwr packet driver collection (including arcether.com, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) one you'll want to use with ARCnet cards) from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) without patches, though, and also doesn't like several cards. Fixed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) versions are available on my WWW page, or via e-mail if you don't have WWW
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) access.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) Installing the Driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) ---------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) All you will need to do in order to install the driver is::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) make config
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) (be sure to choose ARCnet in the network devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) and at least one chipset driver.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) make clean
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) make zImage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) If you obtained this ARCnet package as an upgrade to the ARCnet driver in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) your current kernel, you will need to first copy arcnet.c over the one in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) the linux/drivers/net directory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) You will know the driver is installed properly if you get some ARCnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) messages when you reboot into the new Linux kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) There are four chipset options:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 1. Standard ARCnet COM90xx chipset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) This is the normal ARCnet card, which you've probably got. This is the only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) chipset driver which will autoprobe if not told where the card is.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) It following options on the command line::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) If you load the chipset support as a module, the options are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) io=<io> irq=<irq> shmem=<shmem> device=<name>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) To disable the autoprobe, just specify "com90xx=" on the kernel command line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) To specify the name alone, but allow autoprobe, just put "com90xx=<name>"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) 2. ARCnet COM20020 chipset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) This is the new chipset from SMC with support for promiscuous mode (packet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) sniffing), extra diagnostic information, etc. Unfortunately, there is no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) sensible method of autoprobing for these cards. You must specify the I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) address on the kernel command line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) The command line options are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) If you load the chipset support as a module, the options are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) timeout=<timeout> device=<name>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) The COM20020 chipset allows you to set the node ID in software, overriding the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) default which is still set in DIP switches on the card. If you don't have the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) COM20020 data sheets, and you don't know what the other three options refer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) to, then they won't interest you - forget them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) 3. ARCnet COM90xx chipset in IO-mapped mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) This will also work with the normal ARCnet cards, but doesn't use the shared
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) memory. It performs less well than the above driver, but is provided in case
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) you have a card which doesn't support shared memory, or (strangely) in case
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) you have so many ARCnet cards in your machine that you run out of shmem slots.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) If you don't give the IO address on the kernel command line, then the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) will not find the card.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) The command line options are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) com90io=<io>[,<irq>][,<name>]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) If you load the chipset support as a module, the options are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) io=<io> irq=<irq> device=<name>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) 4. ARCnet RIM I cards.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) These are COM90xx chips which are _completely_ memory mapped. The support for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) these is not tested. If you have one, please mail the author with a success
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) report. All options must be specified, except the device name.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) Command line options::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) If you load the chipset support as a module, the options are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) Loadable Module Support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) Configure and rebuild Linux. When asked, answer 'm' to "Generic ARCnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) support" and to support for your ARCnet chipset if you want to use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) loadable module. You can also say 'y' to "Generic ARCnet support" and 'm'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) to the chipset support if you wish.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) make config
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) make clean
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) make zImage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) make modules
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) If you're using a loadable module, you need to use insmod to load it, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) you can specify various characteristics of your card on the command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) line. (In recent versions of the driver, autoprobing is much more reliable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) and works as a module, so most of this is now unnecessary.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) For example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) cd /usr/src/linux/modules
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) insmod arcnet.o
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) insmod com90xx.o
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) insmod com20020.o io=0x2e0 device=eth1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) Using the Driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) If you build your kernel with ARCnet COM90xx support included, it should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) probe for your card automatically when you boot. If you use a different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) chipset driver complied into the kernel, you must give the necessary options
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) on the kernel command line, as detailed above.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) available where you picked up this driver. Think of your ARCnet as a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) souped-up (or down, as the case may be) Ethernet card.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) By the way, be sure to change all references from "eth0" to "arc0" in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) HOWTOs. Remember that ARCnet isn't a "true" Ethernet, and the device name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) is DIFFERENT.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) Multiple Cards in One Computer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) Linux has pretty good support for this now, but since I've been busy, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) ARCnet driver has somewhat suffered in this respect. COM90xx support, if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) compiled into the kernel, will (try to) autodetect all the installed cards.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) If you have other cards, with support compiled into the kernel, then you can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) just repeat the options on the kernel command line, e.g.::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) If you have the chipset support built as a loadable module, then you need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) do something like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) insmod -o arc0 com90xx
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) insmod -o arc1 com20020 io=0x2e0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) insmod -o arc2 com90xx
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) The ARCnet drivers will now sort out their names automatically.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) How do I get it to work with...?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) NFS:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) Should be fine linux->linux, just pretend you're using Ethernet cards.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients. There
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) is also a DOS-based NFS server called SOSS. It doesn't multitask
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) quite the way Linux does (actually, it doesn't multitask AT ALL) but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) you never know what you might need.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) With AmiTCP (and possibly others), you may need to set the following
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) options in your Amiga nfstab: MD 1024 MR 1024 MW 1024
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) (Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) for this.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) Probably these refer to maximum NFS data/read/write block sizes. I
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) don't know why the defaults on the Amiga didn't work; write to me if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) you know more.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) DOS:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) If you're using the freeware arcether.com, you might want to install
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) the driver patch from my web page. It helps with PC/TCP, and also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) can get arcether to load if it timed out too quickly during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) initialization. In fact, if you use it on a 386+ you REALLY need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) the patch, really.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) Windows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) See DOS :) Trumpet Winsock works fine with either the Novell or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) Arcether client, assuming you remember to load winpkt of course.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) LAN Manager and Windows for Workgroups:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) These programs use protocols that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) are incompatible with the Internet standard. They try to pretend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) the cards are Ethernet, and confuse everyone else on the network.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) However, v2.00 and higher of the Linux ARCnet driver supports this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) protocol via the 'arc0e' device. See the section on "Multiprotocol
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) Support" for more information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) Using the freeware Samba server and clients for Linux, you can now
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) interface quite nicely with TCP/IP-based WfWg or Lan Manager
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) networks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) Windows 95:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) Tools are included with Win95 that let you use either the LANMAN
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) style network drivers (NDIS) or Novell drivers (ODI) to handle your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) ARCnet packets. If you use ODI, you'll need to use the 'arc0'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) device with Linux. If you use NDIS, then try the 'arc0e' device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) See the "Multiprotocol Support" section below if you need arc0e,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) you're completely insane, and/or you need to build some kind of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) hybrid network that uses both encapsulation types.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) OS/2:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) I've been told it works under Warp Connect with an ARCnet driver from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) SMC. You need to use the 'arc0e' interface for this. If you get
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) the SMC driver to work with the TCP/IP stuff included in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) "normal" Warp Bonus Pack, let me know.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) ftp.microsoft.com also has a freeware "Lan Manager for OS/2" client
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) which should use the same protocol as WfWg does. I had no luck
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) installing it under Warp, however. Please mail me with any results.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) NetBSD/AmiTCP:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) These use an old version of the Internet standard ARCnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) protocol (RFC1051) which is compatible with the Linux driver v2.10
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) ALPHA and above using the arc0s device. (See "Multiprotocol ARCnet"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) below.) ** Newer versions of NetBSD apparently support RFC1201.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) Using Multiprotocol ARCnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) "virtual network device":
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) ====== ===============================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) arc0 RFC1201 protocol, the official Internet standard which just
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) happens to be 100% compatible with Novell's TRXNET driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) Version 1.00 of the ARCnet driver supported _only_ this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) protocol. arc0 is the fastest of the three protocols (for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) whatever reason), and allows larger packets to be used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) because it supports RFC1201 "packet splitting" operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) Unless you have a specific need to use a different protocol,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) I strongly suggest that you stick with this one.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) arc0e "Ethernet-Encapsulation" which sends packets over ARCnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) that are actually a lot like Ethernet packets, including the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) 6-byte hardware addresses. This protocol is compatible with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) Microsoft's NDIS ARCnet driver, like the one in WfWg and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) LANMAN. Because the MTU of 493 is actually smaller than the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) one "required" by TCP/IP (576), there is a chance that some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) network operations will not function properly. The Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) TCP/IP layer can compensate in most cases, however, by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) automatically fragmenting the TCP/IP packets to make them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) fit. arc0e also works slightly more slowly than arc0, for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) reasons yet to be determined. (Probably it's the smaller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) MTU that does it.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) arc0s The "[s]imple" RFC1051 protocol is the "previous" Internet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) standard that is completely incompatible with the new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) standard. Some software today, however, continues to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) support the old standard (and only the old standard)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) including NetBSD and AmiTCP. RFC1051 also does not support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) RFC1201's packet splitting, and the MTU of 507 is still
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) smaller than the Internet "requirement," so it's quite
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) possible that you may run into problems. It's also slower
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) than RFC1201 by about 25%, for the same reason as arc0e.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) The arc0s support was contributed by Tomasz Motylewski
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) and modified somewhat by me. Bugs are probably my fault.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) ====== ===============================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) You can choose not to compile arc0e and arc0s into the driver if you want -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) this will save you a bit of memory and avoid confusion when eg. trying to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) use the "NFS-root" stuff in recent Linux kernels.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) The arc0e and arc0s devices are created automatically when you first
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) ifconfig the arc0 device. To actually use them, though, you need to also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) ifconfig the other virtual devices you need. There are a number of ways you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) can set up your network then:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) 1. Single Protocol.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) This is the simplest way to configure your network: use just one of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) two available protocols. As mentioned above, it's a good idea to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) only arc0 unless you have a good reason (like some other software, ie.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) WfWg, that only works with arc0e).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) If you need only arc0, then the following commands should get you going::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) ifconfig arc0 MY.IP.ADD.RESS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) route add MY.IP.ADD.RESS arc0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) route add -net SUB.NET.ADD.RESS arc0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) [add other local routes here]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) If you need arc0e (and only arc0e), it's a little different::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) ifconfig arc0 MY.IP.ADD.RESS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) ifconfig arc0e MY.IP.ADD.RESS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) route add MY.IP.ADD.RESS arc0e
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) route add -net SUB.NET.ADD.RESS arc0e
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) arc0s works much the same way as arc0e.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) 2. More than one protocol on the same wire.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) Now things start getting confusing. To even try it, you may need to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) partly crazy. Here's what *I* did. :) Note that I don't include arc0s in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) my home network; I don't have any NetBSD or AmiTCP computers, so I only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) use arc0s during limited testing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) I have three computers on my home network; two Linux boxes (which prefer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) RFC1201 protocol, for reasons listed above), and one XT that can't run
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) Linux but runs the free Microsoft LANMAN Client instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) Worse, one of the Linux computers (freedom) also has a modem and acts as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) a router to my Internet provider. The other Linux box (insight) also has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) its own IP address and needs to use freedom as its default gateway. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) XT (patience), however, does not have its own Internet IP address and so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) I assigned it one on a "private subnet" (as defined by RFC1597).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) To start with, take a simple network with just insight and freedom.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) Insight needs to:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) - talk to freedom via RFC1201 (arc0) protocol, because I like it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) more and it's faster.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) - use freedom as its Internet gateway.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) That's pretty easy to do. Set up insight like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) ifconfig arc0 insight
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) route add insight arc0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) route add freedom arc0 /* I would use the subnet here (like I said
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) to in "single protocol" above),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) but the rest of the subnet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) unfortunately lies across the PPP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) link on freedom, which confuses
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) things. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) route add default gw freedom
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) And freedom gets configured like so::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) ifconfig arc0 freedom
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) route add freedom arc0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) route add insight arc0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) /* and default gateway is configured by pppd */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) Great, now insight talks to freedom directly on arc0, and sends packets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) to the Internet through freedom. If you didn't know how to do the above,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) you should probably stop reading this section now because it only gets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) worse.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) Now, how do I add patience into the network? It will be using LANMAN
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) Client, which means I need the arc0e device. It needs to be able to talk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) to both insight and freedom, and also use freedom as a gateway to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) Internet. (Recall that patience has a "private IP address" which won't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) work on the Internet; that's okay, I configured Linux IP masquerading on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) freedom for this subnet).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) So patience (necessarily; I don't have another IP number from my
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) provider) has an IP address on a different subnet than freedom and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) insight, but needs to use freedom as an Internet gateway. Worse, most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) DOS networking programs, including LANMAN, have braindead networking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) schemes that rely completely on the netmask and a 'default gateway' to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) determine how to route packets. This means that to get to freedom or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) insight, patience WILL send through its default gateway, regardless of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) the fact that both freedom and insight (courtesy of the arc0e device)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) could understand a direct transmission.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) I compensate by giving freedom an extra IP address - aliased 'gatekeeper' -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) that is on my private subnet, the same subnet that patience is on. I
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) then define gatekeeper to be the default gateway for patience.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) To configure freedom (in addition to the commands above)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) ifconfig arc0e gatekeeper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) route add gatekeeper arc0e
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) route add patience arc0e
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) This way, freedom will send all packets for patience through arc0e,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) giving its IP address as gatekeeper (on the private subnet). When it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) talks to insight or the Internet, it will use its "freedom" Internet IP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) address.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) You will notice that we haven't configured the arc0e device on insight.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) This would work, but is not really necessary, and would require me to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) assign insight another special IP number from my private subnet. Since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) both insight and patience are using freedom as their default gateway, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) two can already talk to each other.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) It's quite fortunate that I set things up like this the first time (cough
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) cough) because it's really handy when I boot insight into DOS. There, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) In this mode it would be impossible for insight to communicate directly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) with patience, since the Novell stack is incompatible with Microsoft's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) Ethernet-Encap. Without changing any settings on freedom or patience, I
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) simply set freedom as the default gateway for insight (now in DOS,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) remember) and all the forwarding happens "automagically" between the two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) hosts that would normally not be able to communicate at all.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) For those who like diagrams, I have created two "virtual subnets" on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) same physical ARCnet wire. You can picture it like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) [RFC1201 NETWORK] [ETHER-ENCAP NETWORK]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) (registered Internet subnet) (RFC1597 private subnet)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) (IP Masquerade)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) /---------------\ * /---------------\
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) | | * | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) | +-Freedom-*-Gatekeeper-+ |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) | | | * | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) \-------+-------/ | * \-------+-------/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) | | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) Insight | Patience
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) (Internet)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) It works: what now?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) Send mail describing your setup, preferably including driver version, kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) version, ARCnet card model, CPU type, number of systems on your network, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) list of software in use to me at the following address:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) apenwarr@worldvisions.ca
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) I do send (sometimes automated) replies to all messages I receive. My email
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) can be weird (and also usually gets forwarded all over the place along the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) way to me), so if you don't get a reply within a reasonable time, please
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) resend.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) It doesn't work: what now?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) Do the same as above, but also include the output of the ifconfig and route
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) commands, as well as any pertinent log entries (ie. anything that starts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) with "arcnet:" and has shown up since the last reboot) in your mail.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) If you want to try fixing it yourself (I strongly recommend that you mail me
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) about the problem first, since it might already have been solved) you may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) want to try some of the debug levels available. For heavy testing on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) first! D_DURING displays 4-5 lines for each packet sent or received. D_TX,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) which is obviously quite big.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) Starting with v2.40 ALPHA, the autoprobe routines have changed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) significantly. In particular, they won't tell you why the card was not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) found unless you turn on the D_INIT_REASONS debugging flag.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) Once the driver is running, you can run the arcdump shell script (available
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) from me or in the full ARCnet package, if you have it) as root to list the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) contents of the arcnet buffers at any time. To make any sense at all out of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) this, you should grab the pertinent RFCs. (some are listed near the top of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) arcnet.c). arcdump assumes your card is at 0xD0000. If it isn't, edit the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) script.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) Ping-pong buffers are implemented both ways.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) the buffers are cleared to a constant value of 0x42 every time the card is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) reset (which should only happen when you do an ifconfig up, or when Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) decides that the driver is broken). During a transmit, unused parts of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) buffer will be cleared to 0x42 as well. This is to make it easier to figure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) out which bytes are being used by a packet.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) You can change the debug level without recompiling the kernel by typing::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) ifconfig arc0 down metric 1xxx
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) /etc/rc.d/rc.inet1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) where "xxx" is the debug level you want. For example, "metric 1015" would put
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) you at debug level 15. Debug level 7 is currently the default.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) Note that the debug level is (starting with v1.90 ALPHA) a binary
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) combination of different debug flags; so debug level 7 is really 1+2+4 or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) D_NORMAL+D_EXTRA+D_INIT. To include D_DURING, you would add 16 to this,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) resulting in debug level 23.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) If you don't understand that, you probably don't want to know anyway.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) E-mail me about your problem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591) I want to send money: what now?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) -------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) Go take a nap or something. You'll feel better in the morning.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags