OpenCores
URL https://opencores.org/ocsvn/or1k_old/or1k_old/trunk

Subversion Repositories or1k_old

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /or1k_old/trunk/rc203soc/sw/uClinux/Documentation/networking
    from Rev 1765 to Rev 1782
    ↔ Reverse comparison
  •

Rev 1765 → Rev 1782

/z8530drv.txt
0,0 → 1,781
This is a subset of the documentation. To use this driver you MUST have the
full package "z8530drv-2.4c.dl1bke.tar.gz" from either ftp.pspt.fi,
sunsite.unc.edu or db0bm.automation.fh-aachen.de. Do not try to use the
utilities from z8530drv-utils-3.0 as they will not work with the 2.4 series
of the driver!
 
---------------------------------------------------------------------------
 
 
SCC.C - Linux driver for Z8530 based HDLC cards for AX.25
 
********************************************************************
 
(c) 1993,1997 by Joerg Reuter DL1BKE
 
portions (c) 1993 Guido ten Dolle PE1NNZ
 
for the complete copyright notice see >> Copying.Z8530DRV <<
 
********************************************************************
 
 
1. Initialization of the driver
===============================
 
To use the driver, 3 steps must be performed:
 
1. if compiled as module: loading the module
2. Setup of hardware, MODEM and KISS parameters with sccinit
3. Attachment of each channel in the packet software
 
 
1.1 Loading the module
======================
 
(If you're going to compile the driver as a part of the kernel image,
skip this chapter and continue with 1.2)
 
Before you can use a module, you'll have to load it with
 
insmod scc.o
 
please read 'man insmod' that comes with modutils.
 
You should include the insmod in one of the /etc/rc.d/rc.* files,
and don't forget to insert a call of sccinit after that. It
will read your
 
 
1.2. /etc/z8530drv.rc
=====================
 
To setup all parameters you must run /sbin/sccinit from one
of your rc.*-files. This has to be done BEFORE the start of
NET or axattach. Sccinit reads the file /etc/z8530drv.rc
and sets the hardware, MODEM and KISS parameters. A sample file is
delivered with this package. Change it to your needs.
 
The file itself consists of two main sections.
 
1.2.1 configuration of hardware parameters
==========================================
 
The hardware setup section defines the following parameters for each
Z8530:
 
chip 1
data_a 0x300 # data port A
ctrl_a 0x304 # control port A
data_b 0x301 # data port B
ctrl_b 0x305 # control port B
irq 5 # IRQ No. 5
pclock 4915200 # clock
board BAYCOM # hardware type
escc no # enhanced SCC chip? (8580/85180/85280)
vector 0 # latch for interrupt vector
special no # address of special function register
option 0 # option to set via sfr
 
 
chip - this is just a delimiter to make sccinit a bit simpler to
program. A parameter has no effect.
 
data_a - the address of the data port A of this Z8530 (needed)
ctrl_a - the address of the control port A (needed)
data_b - the address of the data port B (needed)
ctrl_b - the address of the control port B (needed)
 
irq - the used IRQ for this chip. Different chips can use different
IRQs or the same. If they share an interrupt, it needs to be
specified within one chip-definition only.
 
pclock - the clock at the PCLK pin of the Z8530 (option, 4915200 is
default), measured in Hertz
 
board - the "type" of the board:
 
SCC type value
---------------------------------
PA0HZP SCC card PA0HZP
EAGLE card EAGLE
PC100 card PC100
PRIMUS-PC (DG9BL) card PRIMUS
BayCom (U)SCC card BAYCOM
 
escc - if you want support for ESCC chips (8580, 85180, 85280), set
this to "yes" (option, defaults to "no")
 
vector - address of the vector latch (aka "intack port") for PA0HZP
cards. There can be only one vector latch for all chips!
(option, defaults to 0)
 
special - address of the special function register on several cards.
(option, defaults to 0)
 
option - The value you write into that register (option, default is 0)
 
You can specify up to four chips (8 channels). If this is not enough,
just change
 
#define MAXSCC 4
 
to a higher value.
 
Example for the BayCom USCC:
----------------------------
 
chip 1
data_a 0x300 # data port A
ctrl_a 0x304 # control port A
data_b 0x301 # data port B
ctrl_b 0x305 # control port B
irq 5 # IRQ No. 5 (#)
board BAYCOM # hardware type (*)
#
# SCC chip 2
#
chip 2
data_a 0x302
ctrl_a 0x306
data_b 0x303
ctrl_b 0x307
board BAYCOM
 
An example for a PA0HZP card:
-----------------------------
 
chip 1
data_a 0x153
data_b 0x151
ctrl_a 0x152
ctrl_b 0x150
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
#
#
#
chip 2
data_a 0x157
data_b 0x155
ctrl_a 0x156
ctrl_b 0x154
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
 
A DRSI would should probably work with this:
--------------------------------------------
(actually: two DRSI cards...)
 
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
#
#
#
chip 2
data_a 0x313
data_b 0x311
ctrl_a 0x312
ctrl_b 0x310
irq 7
pclock 4915200
board DRSI
escc no
 
Note that you cannot use the on-board baudrate generator off DRSI
cards. Use "mode dpll" for clock source (see below).
 
This is based on information provided by Mike Bilow (and verified
by Paul Helay)
 
The utility "gencfg"
--------------------
 
If you only know the parameters for the PE1CHL driver for DOS,
run gencfg. It will generate the correct port addresses (I hope).
Its parameters are exactly the same as the ones you use with
the "attach scc" command in net, except that the string "init" must
not appear. Example:
 
gencfg 2 0x150 4 2 0 1 0x168 9 4915200
 
will print a skeleton z8530drv.rc for the OptoSCC to stdout.
 
gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10
 
does the same for the BayCom USCC card. I my opinion it is much easier
to edit scc_config.h...
 
 
1.2.2 channel configuration
===========================
 
The channel definition is divided into three sub sections for each
channel:
 
An example for /dev/scc0:
 
# DEVICE
 
device /dev/scc0 # the device for the following params
 
# MODEM / BUFFERS
 
speed 1200 # the default baudrate
clock dpll # clock source:
# dpll = normal halfduplex operation
# external = MODEM provides own Rx/Tx clock
# divider = use full duplex divider if
# installed (1)
mode nrzi # HDLC encoding mode
# nrzi = 1k2 MODEM, G3RUH 9k6 MODEM
# nrz = DF9IC 9k6 MODEM
#
rxbuffers 8 # number of rx buffers allocated
# (option, default is 4)
txbuffers 16 # number of tx buffers allocated
# (option, default is 16)
bufsize 384 # size of buffers. Note that this must include
# the AX.25 header, not only the data field!
# (optional, defaults to 384)
 
# KISS (Layer 1)
 
txdelay 36 # (see chapter 1.4)
persist 64
slot 8
tail 8
fulldup 0
wait 12
min 3
maxkey 7
idle 3
maxdef 120
group 0
txoff off
softdcd on
slip off
 
The order WITHIN these sections is unimportant. The order OF these
sections IS important. The MODEM parameters are set with the first
recognized KISS parameter...
 
Please note that you can initialize the board only once after boot.
You can change all parameters but "mode" and "clock" later with the
Sccparam program or through KISS. Just to avoid security holes...
 
(1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not
present at all (BayCom). It feeds back the output of the DPLL
(digital pll) as transmit clock. Using this mode without a divider
installed will normally result in keying the transceiver until
maxkey expires --- of course without sending anything (useful).
 
 
2. Attachment of a channel by your AX.25 software
=================================================
 
2.1 KA9Q NOS derivates
======================
 
When the linux has startup, the SCC driver has been initialized,
you can attach the channels in your packet software. This is done
by open the scc devices by using the attach asy command.
The SCC-drivers emulates the scc devices as serial asy ports,
this means e.g. that the baudrate can be set in the attach command.
 
 
Example Wampes:
 
#############################################################################################
# Wampes device attach
# NOTE: Interfacename and the device must be the same!!
# Usage: attach asy 0 0 slip|vjslip|ax25ui|ax25i|nrs|kissui <label> 0 <mtu> <speed> [ip_addr]
#
attach asy 0 0 kissi scc0 256 256 1200 # Attach SCC channel 1 in 1200 baud
attach asy 0 0 kissi scc1 256 256 1200 # Attach SCC channel 2 in 1200 baud
attach asy 0 0 kissui scc2 256 256 38400 # Attach SCC channel 3 in 38400 baud
attach asy 0 0 kissui scc3 256 256 9600 # Attach SCC channel 4 in 9600 baud
# ^^^^
# for WAMPES 921229 use here: ax25
#
 
Example JNOS:
 
############################################
# JNOS device attach
#
attach asy scc0 0 ax25 scc0 256 256 1200
attach asy scc1 0 ax25 scc1 256 256 1200
attach asy scc2 0 ax25 scc2 256 256 300
attach asy scc3 0 ax25 scc3 256 256 4800
#
#
 
 
It allows AX.25 communication without a TNC. Only a MODEM is
needed. The parameters have the same meaning as in KISS mode.
In fact, the AX.25 mode is emulating an extended KISS TNC, so
the same commands can be used to set the parameters of the
interface (see below).
 
To be able to run fullduplex using an SCC in AX.25 mode, an
external divider must be available, that divides the baudrate
generator clock available on the TRxC pin by 32, and puts the
resulting signal on the RTxC pint of the same channel of the SCC.
Such a divider is not necessary for normal CSMA packet radio
operation, but interrupt overhead is slightly reduced if you
still install it.
 
2.2 Kernel AX.25
================
 
Well, as said before: The driver emulates a KISS TNC, so you
can simply run
 
axattach -s 1200 /dev/scc0 DL1BKE
 
to establish the link between kernel AX.25 and z8530drv.
 
 
3. Adjustment and Display of parameters
=======================================
 
3.1 Displaying SCC Parameters:
==============================
 
Once a SCC channel has been attached, the parameter settings and
some statistic information can be shown using the param program:
 
dl1bke-u:~$ sccstat /dev/scc0
 
Parameters:
 
speed : 1200 baud
txdelay : 36
persist : 255
slottime : 0
txtail : 8
fulldup : 1
waittime : 12
mintime : 3 sec
maxkeyup : 7 sec
idletime : 3 sec
maxdefer : 120 sec
group : 0x00
txoff : off
softdcd : on
SLIP : off
 
Status:
 
HDLC Z8530 Interrupts Queues
-----------------------------------------------------------------------
Sent : 273 RxOver : 0 RxInts : 125074 RxQueue : 0
Received : 1095 TxUnder: 0 TxInts : 4684 TxQueue : 0
RxErrors : 1591 ExInts : 11776 NoSpace : 0
KissErrors : 0 SpInts : 1503
Tx State : idle
 
Memory allocated:
 
Buffer size: 384
rx buffers : 4
tx buffers : 8
 
 
The status info shown is:
 
Sent - number of frames transmitted
Received - number of frames received
RxErrors - number of receive errors (CRC, ABORT)
KissErrors - number of KISS errors (should be zero...)
Tx State - status of the Tx interrupt handler: idle/busy/active/tail (2)
RxOver - number of receiver overruns
TxUnder - number of transmitter underruns
RxInts - number of receiver interrupts
TxInts - number of transmitter interrupts
EpInts - number of receiver special condition interrupts
SpInts - number of external/status interrupts
RxQueue - number of received packets enqueued for this channel
TxQueue - number of packets enqueued for Tx
NoSpace - number of times the receiver buffer pool was found empty
 
 
An overrun is abnormal. If lots of these occur, the product of
baudrate and number of interfaces is too high for the processing
power of you computer. If "Space" errors occur, specify a higher
number of buffers in the "scc.h" file.
 
 
3.2 Setting Parameters
======================
 
 
The setting of parameters of the emulated KISS TNC is done in the
same way in the SCC driver. You can change parameters by using
the command param in NET or NOS
 
param <iface> <paramname> <value>
 
or use the program "sccparam":
 
sccparam <device> <paramname> <decimal-|hexadecimal value>
 
You can change the following parameters:
 
param : value
------------------------
speed : 1200
txdelay : 36
persist : 255
slottime : 0
txtail : 8
fulldup : 1
waittime : 12
mintime : 3
maxkeyup : 7
idletime : 3
maxdefer : 120
group : 0x00
txoff : off
softdcd : on
SLIP : off
 
 
The parameters have the following meaning:
 
speed:
The baudrate on this channel in bits/sec
 
Example: sccparam /dev/scc3 speed 9600
 
txdelay:
The delay (in units of 10 ms) after keying of the
transmitter, until the first byte is sent. This is usually
called "TXDELAY" in a TNC. When 0 is specified, the driver
will just wait until the CTS signal is asserted. This
assumes the presence of a timer or other circuitry in the
MODEM and/or transmitter, that asserts CTS when the
transmitter is ready for data.
A normal value of this parameter is 30-36.
 
Example: sccparam /dev/scc0 txd 20
 
persist:
This is the probability that the transmitter will be keyed
when the channel is found to be free. It is a value from 0
to 255, and the probability is (value+1)/256. The value
should be somewhere near 50-60, and should be lowered when
the channel is used more heavily.
 
Example: sccparam /dev/scc2 persist 20
 
slottime:
This is the time between samples of the channel. It is
expressed in units of 10 ms. About 200-300 ms (value 20-30)
seems to be a good value.
 
Example: sccparam /dev/scc0 slot 20
 
tail:
The time the transmitter will remain keyed after the last
byte of a packet has been transferred to the SCC. This is
necessary because the CRC and a flag still have to leave the
SCC before the transmitter is keyed down. The value depends
on the baudrate selected. A few character times should be
sufficient, e.g. 40ms at 1200 baud. (value 4)
The value of this parameter is in 10 ms units.
 
Example: sccparam /dev/scc2 4
 
full:
The full-duplex mode switch. This can be one of the following
values:
 
0: The interface will operate in CSMA mode (the normal
half-duplex packet radio operation)
1: Fullduplex mode, i.e. the transmitter will be keyed at
any time, without checking the received carrier. It
will be unkeyed when there are no packets to be sent.
2: Like 1, but the transmitter will remain keyed, also
when there are no packets to be sent. Flags will be
sent in that case, until a timeout (parameter 10)
occurs.
 
Example: sccparam /dev/scc0 fulldup off
 
wait:
The initial waittime before any transmit attempt, after the
frame has been queue for transmit. This is the length of
the first slot in CSMA mode. In full duplex modes it is
set to 0 for maximum performance.
The value of this parameter is in 10 ms units.
 
Example: sccparam /dev/scc1 wait 4
 
maxkey:
The maximal time the transmitter will be keyed to send
packets, in seconds. This can be useful on busy CSMA
channels, to avoid "getting a bad reputation" when you are
generating a lot of traffic. After the specified time has
elapsed, no new frame will be started. Instead, the trans-
mitter will be switched off for a specified time (parameter
min), and then the selected algorithm for keyup will be
started again.
The value 0 as well as "off" will disable this feature,
and allow infinite transmission time.
 
Example: sccparam /dev/scc0 maxk 20
 
min:
This is the time the transmitter will be switched off when
the maximum transmission time is exceeded.
 
Example: sccparam /dev/scc3 min 10
 
idle
This parameter specifies the maximum idle time in full duplex
2 mode, in seconds. When no frames have been sent for this
time, the transmitter will be keyed down. A value of 0 is
has same result as the fullduplex mode 1. This parameter
can be disabled.
 
Example: sccparam /dev/scc2 idle off # transmit forever
 
maxdefer
This is the maximum time (in seconds) to wait for a free channel
to send. When this timer expires the transmitter will be keyed
IMMEDIATELY. If you love to get trouble with other users you
should set this to a very low value ;-)
 
Example: sccparam /dev/scc0 maxdefer 240 # 2 minutes
 
 
txoff:
When this parameter has the value 0, the transmission of packets
is enable. Otherwise it is disabled.
 
Example: sccparam /dev/scc2 txoff on
 
group:
It is possible to build special radio equipment to use more than
one frequency on the same bad, e.g. using several receivers and
only one transmitter that can be switched between frequencies.
Also, you can connect several radios that are active on the same
band. In these cases, it is not possible, or not a good idea, to
transmit on more than one frequency. The SCC driver provides a
method to lock transmitters on different interfaces, using the
"param <interface> group <x>" command. This will only work when
you are using CSMA mode (parameter full = 0).
The number <x> must be 0 if you want no group restrictions, and
can be computed as follows to create restricted groups:
<x> is the sum of some OCTAL numbers:
 
200 This transmitter will only be keyed when all other
transmitters in the group are off.
100 This transmitter will only be keyed when the carrier
detect of all other interfaces in the group is off.
0xx A byte that can be used to define different groups.
Interfaces are in the same group, when the logical AND
between their xx values is nonzero.
 
Examples:
When 2 interfaces use group 201, their transmitters will never be
keyed at the same time.
When 2 interfaces use group 101, the transmitters will only key
when both channels are clear at the same time. When group 301,
the transmitters will not be keyed at the same time.
 
Don't forget to convert the octal numbers into decimal before
you set the parameter.
 
Example: (to be written)
 
softdcd:
use a software dcd instead of the real one... Useful for a very
slow squelch.
 
Example: sccparam /dev/scc0 soft on
 
 
slip:
use slip encoding instead of kiss
 
Example: sccparam /dev/scc1 slip on
 
 
 
4. Problems
===========
 
If you have tx-problems with your BayCom USCC card please check
the manufacturer of the 8530. SGS chips have a slightly
different timing. Try Zilog... I have no information if this
driver works with baudrates higher than 1200 baud. A solution is
to write to register 8 instead to the data port, but this won't
work with the ESCC chips *SIGH!*
 
I got reports that the driver has problems on some 386-based systems.
(i.e. Amstrad) Those systems have a bogus AT bus timing which will
lead to delayed answers on interrupts. You can recognize these
problems by looking at the output of Sccstat for the suspected
port. See if it shows under- and overruns you own such a system.
Perhaps it will help if you simplify the scc_isr() function a bit.
You'll find a slightly faster version in the files scc_isr_intack
or scc_isr_novec.
 
 
Delayed processing of received data: This depends on
 
- the kernel version
 
- kernel profiling compiled or not
 
- the rather slow receiver in tty_io.c
 
- a high interrupt load
 
- a high load of the machine --- running X, Xmorph, XV and Povray,
while compiling the kernel... hmm ... even with 32 MB RAM ... ;-)
 
- NET's speed itself.
 
 
Kernel panics: please read to /linux/README and find out if it
really occurred within the scc driver.
 
If you can't solve a problem, send me
 
- a description of the problem,
- information on your hardware (computer system, scc board, modem)
- your kernel version
- the output of sccstat /dev/scc# ("#" is the No. of the channel)
- the settings of "speed", "clock" and "mode" for that channel
in /etc/z8530drv.rc
- your scc_config.h
 
 
And always remember:
The 1.1.* kernel series is for alpha tests -- use at your own risk ;-)
The 1.2.* series should run reliable. This driver perhaps NOT!
The 1.3.* kernel series is for alpha tests again... you get the idea!
 
 
3. DRSI Boards
==============
 
I still can't test the DRSI board, but this configuration derived from
the PE1CHL SCC driver configuration should work:
 
An example of scc_config.h for
 
One DRSI board installed:
=========================
 
/* gencfg 1 0x300 0x10 2 0 1 0 7 4915200 */
 
/* file generated by $Id: z8530drv.txt,v 1.1 2005-12-20 10:06:05 jcastillo Exp $ */
 
#include <linux/scc.h>
 
int Nchips = 1;
io_port Vector_Latch = 0x0;
int Ivec = 7;
long Clock = 4915200;
char Board = PA0HZP;
int Option = 0;
io_port Special_Port = 0x0;
 
io_port SCC_ctrl[MAXSCC * 2] =
{0x302, 0x300, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
 
io_port SCC_data[MAXSCC * 2] =
{0x303, 0x301, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
 
/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */
 
/* Chip */
/* ======== */
int SCC_Enhanced[MAXSCC] = {0, /* ...one... */
0, /* ...two... */
0, /* ...three... */
0}; /* ...four... */
 
#define VERBOSE_BOOTMSG 1
#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */
#undef SCC_LDELAY /* slow it even a bit more down */
#undef DONT_CHECK /* don't look if the SCCs you specified are available */
 
 
 
Two boards installed:
=====================
 
/* file generated by $Id: z8530drv.txt,v 1.1 2005-12-20 10:06:05 jcastillo Exp $ */
 
#include <linux/scc.h>
 
int Nchips = 2;
io_port Vector_Latch = 0x0;
int Ivec = 7;
long Clock = 4915200;
char Board = PA0HZP;
int Option = 0;
io_port Special_Port = 0x0;
 
io_port SCC_ctrl[MAXSCC * 2] =
{0x302, 0x300, 0x312, 0x310, 0x0, 0x0, 0x0, 0x0};
 
io_port SCC_data[MAXSCC * 2] =
{0x303, 0x301, 0x313, 0x311, 0x0, 0x0, 0x0, 0x0};
 
/* set to '1' if you have and want ESCC chip (8580/85180/85280) support */
 
/* Chip */
/* ======== */
int SCC_Enhanced[MAXSCC] = {0, /* ...one... */
0, /* ...two... */
0, /* ...three... */
0}; /* ...four... */
 
#define VERBOSE_BOOTMSG 1
#undef SCC_DELAY /* perhaps a 486DX2 is a *bit* too fast */
#undef SCC_LDELAY /* slow it even a bit more down */
#undef DONT_CHECK /* don't look if the SCCs you specified are available */
 
 
*****************
 
You m u s t use "clock dpll" in /etc/z8530drv.rc for operation,
the on-board baudrate generator is not supported.
 
*****************
(mni tnx to Mike Bilow)
 
 
4. Thor RLC100
==============
 
Mysteriously this board seems not to work with the driver. Anyone
got it up-and-running?
 
 
Many thanks to Linus Torvalds and Alan Cox for including the driver
in the Linux standard distribution and their support.
 
Joerg Reuter ampr-net: dl1bke@db0pra.ampr.org
WWW : http://www.rat.de/jr
Internet: jreuter@poboxes.com
/00-INDEX
0,0 → 1,45
00-INDEX
- this file
3c505.txt
- information on the 3Com EtherLink Plus (3c505) driver.
Configurable
- info on some of the configurable network parameters
alias.txt
- info on using alias network devices
arcnet-hardware.txt
- tons of info on arcnet, hubs, arcnet card jumper settings, etc.
arcnet.txt
- info on the using the arcnet driver itself.
ax25.txt
- info on using AX.25 and NET/ROM code for Linux
depca.txt
- the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
framerelay.txt
- info on using Frame Relay/Data Link Connection Identifier (DLCI).
ip_dynaddr.txt
- info on using dynamic IP addressing for diald and IP masquerading.
ipx.txt
- info on the two possible modes of kernel IPX network support.
masquerading.txt
- using IP masquerading, multiple machines using a single IP address.
ncsa-telnet
- notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
net-modules.txt
- info and "insmod" parameters for all network driver modules.
ppp.txt
- info on what software you should use to run PPP.
so_bindtodevice.txt
- info on binding a socket to a specific device/interface.
tcp.txt
- short blurb on how TCP output takes place.
tlan.FAQ
- freq. asked questions on the TLAN (Compaq Netelligent) driver.
tlan.README
- usage and supported hardware info for the Thunderlan driver.
tulip.txt
- info on using DEC 21040/21041/21140 based PCI Ethernet cards.
vortex.txt
- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) e'net cards.
z8530drv.txt
- info about Linux driver for Z8530 based HDLC cards for AX.25
 
/arcnet-hardware.txt
0,0 → 1,3134
-----------------------------------------------------------------------------
1) This file is a supplement to arcnet.txt. Please read that for general
driver configuration help.
-----------------------------------------------------------------------------
2) This file is no longer Linux-specific. It should probably be moved out of
the kernel sources. Ideas?
-----------------------------------------------------------------------------
 
Because so many people (myself included) seem to have obtained ARCnet cards
without manuals, this file contains a quick introduction to ARCnet hardware,
some cabling tips, and a listing of all jumper settings I can find. Please
e-mail apenwarr@foxnet.net with any settings for your particular card, or
any other information you have!
 
 
INTRODUCTION TO ARCNET
----------------------
 
ARCnet is a network type which works in a way similar to popular Ethernet
networks but which is also different in some very important ways.
 
First of all, you can get ARCnet cards in at least two speeds: 2.5 Mbps
(slower than Ethernet) and 100 Mbps (faster than normal Ethernet). In fact,
there are others as well, but these are less common. The different hardware
types, as far as I'm aware, are not compatible and so you cannot wire a
100 Mbps card to a 2.5 Mbps card, and so on. From what I hear, my driver does
work with 100 Mbps cards, but I haven't been able to verify this myself,
since I only have the 2.5 Mbps variety. It is probably not going to saturate
your 100 Mbps card. Stop complaining :)
 
You also cannot connect an ARCnet card to any kind of Ethernet card and
expect it to work.
 
There are two "types" of ARCnet - STAR topology and BUS topology. This
refers to how the cards are meant to be wired together. According to most
available documentation, you can only connect STAR cards to STAR cards and
BUS cards to BUS cards. That makes sense, right? Well, it's not quite
true; see below under "Cabling."
 
Once you get past these little stumbling blocks, ARCnet is actually quite a
well-designed standard. It uses something called "modified token passing"
which makes it completely incompatible with so-called "Token Ring" cards,
but which makes transfers much more reliable than Ethernet does. In fact,
ARCnet will guarantee that a packet arrives safely at the destination, and
even if it can't possibly be delivered properly (ie. because of a cable
break, or because the destination computer does not exist) it will at least
tell the sender about it.
 
Because of the carefully defined action of the "token", it will always make
a pass around the "ring" within a maximum length of time. This makes it
useful for realtime networks.
 
In addition, all known ARCnet cards have an (almost) identical programming
interface. This means that with one "arcnet" driver you can support any
card; whereas, with Ethernet, each manufacturer uses what is sometimes a
completely different programming interface, leading to a lot of different,
sometimes very similar, Ethernet drivers. Of course, always using the same
programming interface also means that when high-performance hardware
facilities like PCI busmastering DMA appear, it's hard to take advantage of
them. Let's not go into that.
 
One thing that makes ARCnet cards difficult to program for, however, is the
limit on their packet sizes; standard ARCnet can only send packets that are
up to 508 bytes in length. This is smaller than the internet "bare minimum"
of 576 bytes, let alone the Ethernet MTU of 1500. To compensate, an extra
level of encapsulation is defined by RFC1201, which I call "packet
splitting," that allows "virtual packets" to grow as large as 64K each,
although they are generally kept down to the Ethernet-style 1500 bytes.
 
For more information on the advantages and disadvantages (mostly the
advantages) of ARCnet networks, you might try the "ARCnet Trade Association"
WWW page:
http://www.arcnet.com
 
 
CABLING ARCNET NETWORKS
-----------------------
 
This section was rewritten by
Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
using information from several people, including:
Avery Pennraun <apenwarr@foxnet.net>
Stephen A. Wood <saw@hallc1.cebaf.gov>
John Paul Morrison <jmorriso@bogomips.ee.ubc.ca>
Joachim Koenig <jojo@repas.de>
and Avery touched it up a bit, at Vojtech's request.
 
ARCnet (the classic 2.5 Mbps version) can be connected by two different
types of cabling: coax and twisted pair. The other ARCnet-type networks
(100 Mbps TCNS and 320 kbps - 32 Mbps ARCnet Plus) use different types of
cabling (Type1, Fiber, C1, C4, C5).
 
For a coax network, you "should" use 93 Ohm RG-62 cable. But other cables
also work fine, because ARCnet is a very stable network. I personally use 75
Ohm TV antenna cable.
 
Cards for coax cabling are shipped in two different variants: for BUS and
STAR network topologies. They are mostly the same. The only difference
lies in the hybrid chip installed. BUS cards use high impedance output,
while STAR use low impedance. Low impedance card (STAR) is electrically
equal to a high impedance one with a terminator installed.
 
Usually, the ARCnet networks are built up from STAR cards and hubs. There
are two types of hubs - active and passive. Passive hubs are small boxes
with four BNC connectors containing four 47 Ohm resistors:
 
| | wires
R + junction
-R-+-R- R 47 Ohm resistors
R
|
 
The shielding is connected together. Active hubs are much more complicated;
they are powered and contain electronics to amplify the signal and send it
to other segments of the net. They usually have eight connectors. Active
hubs come in two variants - dumb and smart. The dumb variant just
amplifies, but the smart one decodes to digital and encodes back all packets
coming through. This is much better if you have several hubs in the net,
since many dumb active hubs may worsen the signal quality.
 
And now to the cabling. What you can connect together:
 
1. A card to a card. This is the simplest way of creating a 2-computer
network.
 
2. A card to a passive hub. Remember that all unused connectors on the hub
must be properly terminated with 93 Ohm (or something else if you don't
have the right ones) terminators.
(Avery's note: oops, I didn't know that. Mine (TV cable) works
anyway, though.)
 
3. A card to an active hub. Here is no need to terminate the unused
connectors except some kind of aesthetic feeling. But, there may not be
more than eleven active hubs between any two computers. That of course
doesn't limit the number of active hubs on the network.
4. An active hub to another.
 
5. An active hub to passive hub.
 
Remember, that you can not connect two passive hubs together. The power loss
implied by such a connection is too high for the net to operate reliably.
 
An example of a typical ARCnet network:
 
R S - STAR type card
S------H--------A-------S R - Terminator
| | H - Hub
| | A - Active hub
| S----H----S
S |
|
S
The BUS topology is very similar to the one used by Ethernet. The only
difference is in cable and terminators: they should be 93 Ohm. Ethernet
uses 50 Ohm impedance. You use T connectors to put the computers on a single
line of cable, the bus. You have to put terminators at both ends of the
cable. A typical BUS ARCnet network looks like:
 
RT----T------T------T------T------TR
B B B B B B
 
B - BUS type card
R - Terminator
T - T connector
 
But that is not all! The two types can be connected together. According to
the official documentation the only way of connecting them is using an active
hub:
 
A------T------T------TR
| B B B
S---H---S
|
S
 
The official docs also state that you can use STAR cards at the ends of
BUS network in place of a BUS card and a terminator:
 
S------T------T------S
B B
 
But, according to my own experiments, you can simply hang a BUS type card
anywhere in middle of a cable in a STAR topology network. And more - you
can use the bus card in place of any star card if you use a terminator. Then
you can build very complicated networks fulfilling all your needs! An
example:
 
S
|
RT------T-------T------H------S
B B B |
| R
S------A------T-------T-------A-------H------TR
| B B | | B
| S BT |
| | | S----A-----S
S------H---A----S | |
| | S------T----H---S |
S S B R S
A basically different cabling scheme is used with Twisted Pair cabling. Each
of the TP cards has two RJ (phone-cord style) connectors. The cards are
then daisy-chained together using a cable connecting every two neighboring
cards. The ends are terminated with RJ 93 Ohm terminators which plug into
the empty connectors of cards on the ends of the chain. An example:
 
___________ ___________
_R_|_ _|_|_ _|_R_
| | | | | |
|Card | |Card | |Card |
|_____| |_____| |_____|
 
 
There are also hubs for the TP topology. There is nothing difficult
involved in using them; you just connect a TP chain to a hub on any end or
even at both. This way you can create almost any network configuration.
The maximum of 11 hubs between any two computers on the net applies here as
well. An example:
 
RP-------P--------P--------H-----P------P-----PR
|
RP-----H--------P--------H-----P------PR
| |
PR PR
 
R - RJ Terminator
P - TP Card
H - TP Hub
 
Like any network, ARCnet has a limited cable length. These are the maximum
cable lengths between two active ends (an active end being an active hub or
a STAR card).
 
RG-62 93 Ohm up to 650 m
RG-59/U 75 Ohm up to 457 m
RG-11/U 75 Ohm up to 533 m
IBM Type 1 150 Ohm up to 200 m
IBM Type 3 100 Ohm up to 100 m
 
The maximum length of all cables connected to a passive hub is limited to 65
meters for RG-62 cabling; less for others. You can see that using passive
hubs in a large network is a bad idea. The maximum length of a single "BUS
Trunk" is about 300 meters for RG-62. The maximum distance between the two
most distant points of the net is limited to 3000 meters. The maximum length
of a TP cable between two cards/hubs is 650 meters.
 
 
SETTING THE JUMPERS
-------------------
 
All ARCnet cards should have a total of four or five different settings:
 
- the I/O address: this is the "port" your ARCnet card is on. Probed
values in the Linux ARCnet driver are only from 0x200 through 0x3F0. (If
your card has additional ones, which is possible, please tell me.) This
should not be the same as any other device on your system. According to
a doc I got from Novell, MS Windows prefers values of 0x300 or more,
eating net connections on my system (at least) otherwise. My guess is
this may be because, if your card is at 0x2E0, probing for a serial port
at 0x2E8 will reset the card and probably mess things up royally.
- Avery's favourite: 0x300.
 
- the IRQ: on 8-bit cards, it might be 2 (9), 3, 4, 5, or 7.
on 16-bit cards, it might be 2 (9), 3, 4, 5, 7, or 10-15.
Make sure this is different from any other card on your system. Note
that IRQ2 is the same as IRQ9, as far as Linux is concerned. You can
"cat /proc/interrupts" for a somewhat complete list of which ones are in
use at any given time. Here is a list of common usages from Vojtech
Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>:
("Not on bus" means there is no way for a card to generate this
interrupt)
IRQ 0 - Timer 0 (Not on bus)
IRQ 1 - Keyboard (Not on bus)
IRQ 2 - IRQ Controller 2 (Not on bus, nor does interrupt the CPU)
IRQ 3 - COM2
IRQ 4 - COM1
IRQ 5 - FREE (LPT2 if you have it; sometimes COM3; maybe PLIP)
IRQ 6 - Floppy disk controller
IRQ 7 - FREE (LPT1 if you don't use the polling driver; PLIP)
IRQ 8 - Realtime Clock Interrupt (Not on bus)
IRQ 9 - FREE (VGA vertical sync interrupt if enabled)
IRQ 10 - FREE
IRQ 11 - FREE
IRQ 12 - FREE
IRQ 13 - Numeric Coprocessor (Not on bus)
IRQ 14 - Fixed Disk Controller
IRQ 15 - FREE (Fixed Disk Controller 2 if you have it)
Note: IRQ 9 is used on some video cards for the "vertical retrace"
interrupt. This interrupt would have been handy for things like
video games, as it occurs exactly once per screen refresh, but
unfortunately IBM cancelled this feature starting with the original
VGA and thus many VGA/SVGA cards do not support it. For this
reason, no modern software uses this interrupt and it can almost
always be safely disabled, if your video card supports it at all.
If your card for some reason CANNOT disable this IRQ (usually there
is a jumper), one solution would be to clip the printed circuit
contact on the board: it's the fourth contact from the left on the
back side. I take no responsibility if you try this.
 
- Avery's favourite: IRQ2 (actually IRQ9). Watch that VGA, though.
 
- the memory address: Unlike most cards, ARCnets use "shared memory" for
copying buffers around. Make SURE it doesn't conflict with any other
used memory in your system!
A0000 - VGA graphics memory (ok if you don't have VGA)
B0000 - Monochrome text mode
C0000 \ One of these is your VGA BIOS - usually C0000.
E0000 /
F0000 - System BIOS
 
Anything less than 0xA0000 is, well, a BAD idea since it isn't above
640k.
- Avery's favourite: 0xD0000
 
- the station address: Every ARCnet card has its own "unique" network
address from 0 to 255. Unlike Ethernet, you can set this address
yourself with a jumper or switch (or on some cards, with special
software). Since it's only 8 bits, you can only have 254 ARCnet cards
on a network. DON'T use 0 or 255, since these are reserved (although
neat stuff will probably happen if you DO use them). By the way, if you
haven't already guessed, don't set this the same as any other ARCnet on
your network!
- Avery's favourite: 3 and 4. Not that it matters.
 
- There may be ETS1 and ETS2 settings. These may or may not make a
difference on your card (many manuals call them "reserved"), but are
used to change the delays used when powering up a computer on the
network. This is only necessary when wiring VERY long range ARCnet
networks, on the order of 4km or so; in any case, the only real
requirement here is that all cards on the network with ETS1 and ETS2
jumpers have them in the same position. Chris Hindy <chrish@io.org>
sent in a chart with actual values for this:
ET1 ET2 Response Time Reconfiguration Time
--- --- ------------- --------------------
open open 74.7us 840us
open closed 283.4us 1680us
closed open 561.8us 1680us
closed closed 1118.6us 1680us
Make sure you set ETS1 and ETS2 to the SAME VALUE for all cards on your
network.
Also, on many cards (not mine, though) there are red and green LED's.
Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz> tells me this is what they
mean:
GREEN RED Status
----- --- ------
OFF OFF Power off
OFF Short flashes Cabling problems (broken cable or not
terminated)
OFF (short) ON Card init
ON ON Normal state - everything OK, nothing
happens
ON Long flashes Data transfer
ON OFF Never happens (maybe when wrong ID)
 
 
The following is all the specific information people have sent me about
their own particular ARCnet cards. It is officially a mess, and contains
huge amounts of duplicated information. I have no time to fix it. If you
want to, PLEASE DO! Just send me a 'diff -u' of all your changes.
 
The model # is listed right above specifics for that card, so you should be
able to use your text viewer's "search" function to find the entry you want.
If you don't KNOW what kind of card you have, try looking through the
various diagrams to see if you can tell.
 
If your model isn't listed and/or has different settings, PLEASE PLEASE
tell me. I had to figure mine out without the manual, and it WASN'T FUN!
 
Even if your ARCnet model isn't listed, but has the same jumpers as another
model that is, please e-mail me to say so.
 
Cards Listed in this file (in this order, mostly):
 
Manufacturer Model # Bits
------------ ------- ----
SMC PC100 8
SMC PC110 8
SMC PC120 8
SMC PC130 8
SMC PC270E 8
SMC PC500 16
SMC PC500Longboard 16
SMC PC550Longboard 16
SMC PC600 16
SMC PC710 8
SMC? LCS-8830(-T) 8/16
Puredata PDI507 8
CNet Tech CN120-Series 8
CNet Tech CN160-Series 16
Lantech? UM9065L chipset 8
Acer 5210-003 8
Datapoint? LAN-ARC-8 8
Topware TA-ARC/10 8
Thomas-Conrad 500-6242-0097 REV A 8
Waterloo? (C)1985 Waterloo Micro. 8
No Name -- 8/16
No Name Taiwan R.O.C? 8
No Name Model 9058 8
Tiara Tiara Lancard? 8
 
** SMC = Standard Microsystems Corp.
** CNet Tech = CNet Technology, Inc.
 
 
Unclassified Stuff
------------------
- Please send any other information you can find.
- And some other stuff (more info is welcome!):
From: root@ultraworld.xs4all.nl (Timo Hilbrink)
To: apenwarr@foxnet.net (Avery Pennarun)
Date: Wed, 26 Oct 1994 02:10:32 +0000 (GMT)
Reply-To: timoh@xs4all.nl
 
[...parts deleted...]
 
About the jumpers: On my PC130 there is one more jumper, located near the
cable-connector and it's for changing to star or bus topology;
closed: star - open: bus
On the PC500 are some more jumper-pins, one block labeled with RX,PDN,TXI
and another with ALE,LA17,LA18,LA19 these are undocumented..
 
[...more parts deleted...]
 
--- CUT ---
 
 
** Standard Microsystems Corp (SMC) **
PC100, PC110, PC120, PC130 (8-bit cards)
PC500, PC600 (16-bit cards)
---------------------------------
- mainly from Avery Pennarun <apenwarr@foxnet.net>. Values depicted are
from Avery's setup.
- special thanks to Timo Hilbrink <timoh@xs4all.nl> for noting that PC120,
130, 500, and 600 all have the same switches as Avery's PC100.
PC500/600 have several extra, undocumented pins though. (?)
- PC110 settings were verified by Stephen A. Wood <saw@cebaf.gov>
- Also, the JP- and S-numbers probably don't match your card exactly. Try
to find jumpers/switches with the same number of settings - it's
probably more reliable.
 
JP5 [|] : : : :
(IRQ Setting) IRQ2 IRQ3 IRQ4 IRQ5 IRQ7
Put exactly one jumper on exactly one set of pins.
 
 
1 2 3 4 5 6 7 8 9 10
S1 /----------------------------------\
(I/O and Memory | 1 1 * 0 0 0 0 * 1 1 0 1 |
addresses) \----------------------------------/
|--| |--------| |--------|
(a) (b) (m)
WARNING. It's very important when setting these which way
you're holding the card, and which way you think is '1'!
If you suspect that your settings are not being made
correctly, try reversing the direction or inverting the
switch positions.
 
a: The first digit of the I/O address.
Setting Value
------- -----
00 0
01 1
10 2
11 3
 
b: The second digit of the I/O address.
Setting Value
------- -----
0000 0
0001 1
0010 2
... ...
1110 E
1111 F
 
The I/O address is in the form ab0. For example, if
a is 0x2 and b is 0xE, the address will be 0x2E0.
 
DO NOT SET THIS LESS THAN 0x200!!!!!
 
 
m: The first digit of the memory address.
Setting Value
------- -----
0000 0
0001 1
0010 2
... ...
1110 E
1111 F
 
The memory address is in the form m0000. For example, if
m is D, the address will be 0xD0000.
 
DO NOT SET THIS TO C0000, F0000, OR LESS THAN A0000!
 
1 2 3 4 5 6 7 8
S2 /--------------------------\
(Station Address) | 1 1 0 0 0 0 0 0 |
\--------------------------/
 
Setting Value
------- -----
00000000 00
10000000 01
01000000 02
...
01111111 FE
11111111 FF
 
Note that this is binary with the digits reversed!
 
DO NOT SET THIS TO 0 OR 255 (0xFF)!
 
 
*****************************************************************************
 
** Standard Microsystems Corp (SMC) **
PC130E/PC270E (8-bit cards)
---------------------------
- from Juergen Seifert <seifert@htwm.de>
 
 
STANDARD MICROSYSTEMS CORPORATION (SMC) ARCNET(R)-PC130E/PC270E
===============================================================
 
This description has been written by Juergen Seifert <seifert@htwm.de>
using information from the following Original SMC Manual
 
"Configuration Guide for
ARCNET(R)-PC130E/PC270
Network Controller Boards
Pub. # 900.044A
June, 1989"
 
ARCNET is a registered trademark of the Datapoint Corporation
SMC is a registered trademark of the Standard Microsystems Corporation
 
The PC130E is an enhanced version of the PC130 board, is equipped with a
standard BNC female connector for connection to RG-62/U coax cable.
Since this board is designed both for point-to-point connection in star
networks and for connection to bus networks, it is downwardly compatible
with all the other standard boards designed for coax networks (that is,
the PC120, PC110 and PC100 star topology boards and the PC220, PC210 and
PC200 bus topology boards).
 
The PC270E is an enhanced version of the PC260 board, is equipped with two
modular RJ11-type jacks for connection to twisted pair wiring.
It can be used in a star or a daisy-chained network.
 
 
8 7 6 5 4 3 2 1
________________________________________________________________
| | S1 | |
| |_________________| |
| Offs|Base |I/O Addr |
| RAM Addr | ___|
| ___ ___ CR3 |___|
| | \/ | CR4 |___|
| | PROM | ___|
| | | N | | 8
| | SOCKET | o | | 7
| |________| d | | 6
| ___________________ e | | 5
| | | A | S | 4
| |oo| EXT2 | | d | 2 | 3
| |oo| EXT1 | SMC | d | | 2
| |oo| ROM | 90C63 | r |___| 1
| |oo| IRQ7 | | |o| _____|
| |oo| IRQ5 | | |o| | J1 |
| |oo| IRQ4 | | STAR |_____|
| |oo| IRQ3 | | | J2 |
| |oo| IRQ2 |___________________| |_____|
|___ ______________|
| |
|_____________________________________________|
 
Legend:
 
SMC 90C63 ARCNET Controller / Transceiver /Logic
S1 1-3: I/O Base Address Select
4-6: Memory Base Address Select
7-8: RAM Offset Select
S2 1-8: Node ID Select
EXT Extended Timeout Select
ROM ROM Enable Select
STAR Selected - Star Topology (PC130E only)
Deselected - Bus Topology (PC130E only)
CR3/CR4 Diagnostic LEDs
J1 BNC RG62/U Connector (PC130E only)
J1 6-position Telephone Jack (PC270E only)
J2 6-position Telephone Jack (PC270E only)
 
Setting one of the switches to Off/Open means "1", On/Closed means "0".
 
 
Setting the Node ID
-------------------
 
The eight switches in group S2 are used to set the node ID.
These switches work in a way similar to the PC100-series cards; see that
entry for more information.
 
 
Setting the I/O Base Address
----------------------------
 
The first three switches in switch group S1 are used to select one
of eight possible I/O Base addresses using the following table
 
 
Switch | Hex I/O
1 2 3 | Address
-------|--------
0 0 0 | 260
0 0 1 | 290
0 1 0 | 2E0 (Manufacturer's default)
0 1 1 | 2F0
1 0 0 | 300
1 0 1 | 350
1 1 0 | 380
1 1 1 | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer requires 2K of a 16K block of RAM. The base of this
16K block can be located in any of eight positions.
Switches 4-6 of switch group S1 select the Base of the 16K block.
Within that 16K address space, the buffer may be assigned any one of four
positions, determined by the offset, switches 7 and 8 of group S1.
 
Switch | Hex RAM | Hex ROM
4 5 6 7 8 | Address | Address *)
-----------|---------|-----------
0 0 0 0 0 | C0000 | C2000
0 0 0 0 1 | C0800 | C2000
0 0 0 1 0 | C1000 | C2000
0 0 0 1 1 | C1800 | C2000
| |
0 0 1 0 0 | C4000 | C6000
0 0 1 0 1 | C4800 | C6000
0 0 1 1 0 | C5000 | C6000
0 0 1 1 1 | C5800 | C6000
| |
0 1 0 0 0 | CC000 | CE000
0 1 0 0 1 | CC800 | CE000
0 1 0 1 0 | CD000 | CE000
0 1 0 1 1 | CD800 | CE000
| |
0 1 1 0 0 | D0000 | D2000 (Manufacturer's default)
0 1 1 0 1 | D0800 | D2000
0 1 1 1 0 | D1000 | D2000
0 1 1 1 1 | D1800 | D2000
| |
1 0 0 0 0 | D4000 | D6000
1 0 0 0 1 | D4800 | D6000
1 0 0 1 0 | D5000 | D6000
1 0 0 1 1 | D5800 | D6000
| |
1 0 1 0 0 | D8000 | DA000
1 0 1 0 1 | D8800 | DA000
1 0 1 1 0 | D9000 | DA000
1 0 1 1 1 | D9800 | DA000
| |
1 1 0 0 0 | DC000 | DE000
1 1 0 0 1 | DC800 | DE000
1 1 0 1 0 | DD000 | DE000
1 1 0 1 1 | DD800 | DE000
| |
1 1 1 0 0 | E0000 | E2000
1 1 1 0 1 | E0800 | E2000
1 1 1 1 0 | E1000 | E2000
1 1 1 1 1 | E1800 | E2000
*) To enable the 8K Boot PROM install the jumper ROM.
The default is jumper ROM not installed.
 
 
Setting the Timeouts and Interrupt
----------------------------------
 
The jumpers labeled EXT1 and EXT2 are used to determine the timeout
parameters. These two jumpers are normally left open.
 
To select a hardware interrupt level set one (only one!) of the jumpers
IRQ2, IRQ3, IRQ4, IRQ5, IRQ7. The Manufacturer's default is IRQ2.
 
Configuring the PC130E for Star or Bus Topology
-----------------------------------------------
 
The single jumper labeled STAR is used to configure the PC130E board for
star or bus topology.
When the jumper is installed, the board may be used in a star network, when
it is removed, the board can be used in a bus topology.
 
 
Diagnostic LEDs
---------------
 
Two diagnostic LEDs are visible on the rear bracket of the board.
The green LED monitors the network activity: the red one shows the
board activity:
 
Green | Status Red | Status
-------|------------------- ---------|-------------------
on | normal activity flash/on | data transfer
blink | reconfiguration off | no data transfer;
off | defective board or | incorrect memory or
| node ID is zero | I/O address
 
 
*****************************************************************************
 
** Standard Microsystems Corp (SMC) **
PC500/PC550 Longboard (16-bit cards)
-------------------------------------
- from Juergen Seifert <seifert@htwm.de>
 
 
STANDARD MICROSYSTEMS CORPORATION (SMC) ARCNET-PC500/PC550 Long Board
=====================================================================
 
Note: There is another Version of the PC500 called Short Version, which
is different in hard- and software! The most important differences
are:
- The long board has no Shared memory.
- On the long board the selection of the interrupt is done by binary
coded switch, on the short board directly by jumper.
[Avery's note: pay special attention to that: the long board HAS NO SHARED
MEMORY. This means the current Linux-ARCnet driver can't use these cards.
I have obtained a PC500Longboard and will be doing some experiments on it in
the future, but don't hold your breath. Thanks again to Juergen Seifert for
his advice about this!]
 
This description has been written by Juergen Seifert <seifert@htwm.de>
using information from the following Original SMC Manual
 
"Configuration Guide for
SMC ARCNET-PC500/PC550
Series Network Controller Boards
Pub. # 900.033 Rev. A
November, 1989"
 
ARCNET is a registered trademark of the Datapoint Corporation
SMC is a registered trademark of the Standard Microsystems Corporation
 
The PC500 is equipped with a standard BNC female connector for connection
to RG-62/U coax cable.
The board is designed both for point-to-point connection in star networks
and for connection to bus networks.
 
The PC550 is equipped with two modular RJ11-type jacks for connection
to twisted pair wiring.
It can be used in a star or a daisy-chained (BUS) network.
 
1
0 9 8 7 6 5 4 3 2 1 6 5 4 3 2 1
____________________________________________________________________
< | SW1 | | SW2 | |
> |_____________________| |_____________| |
< IRQ |I/O Addr |
> ___|
< CR4 |___|
> CR3 |___|
< ___|
> N | | 8
< o | | 7
> d | S | 6
< e | W | 5
> A | 3 | 4
< d | | 3
> d | | 2
< r |___| 1
> |o| _____|
< |o| | J1 |
> 3 1 JP6 |_____|
< |o|o| JP2 | J2 |
> |o|o| |_____|
< 4 2__ ______________|
> | | |
<____| |_____________________________________________|
 
Legend:
 
SW1 1-6: I/O Base Address Select
7-10: Interrupt Select
SW2 1-6: Reserved for Future Use
SW3 1-8: Node ID Select
JP2 1-4: Extended Timeout Select
JP6 Selected - Star Topology (PC500 only)
Deselected - Bus Topology (PC500 only)
CR3 Green Monitors Network Activity
CR4 Red Monitors Board Activity
J1 BNC RG62/U Connector (PC500 only)
J1 6-position Telephone Jack (PC550 only)
J2 6-position Telephone Jack (PC550 only)
 
Setting one of the switches to Off/Open means "1", On/Closed means "0".
 
 
Setting the Node ID
-------------------
 
The eight switches in group SW3 are used to set the node ID. Each node
attached to the network must have an unique node ID which must be
different from 0.
Switch 1 serves as the least significant bit (LSB).
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Value
-------|-------
1 | 1
2 | 2
3 | 4
4 | 8
5 | 16
6 | 32
7 | 64
8 | 128
 
Some Examples:
 
Switch | Hex | Decimal
8 7 6 5 4 3 2 1 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed
0 0 0 0 0 0 0 1 | 1 | 1
0 0 0 0 0 0 1 0 | 2 | 2
0 0 0 0 0 0 1 1 | 3 | 3
. . . | |
0 1 0 1 0 1 0 1 | 55 | 85
. . . | |
1 0 1 0 1 0 1 0 | AA | 170
. . . | |
1 1 1 1 1 1 0 1 | FD | 253
1 1 1 1 1 1 1 0 | FE | 254
1 1 1 1 1 1 1 1 | FF | 255
 
 
Setting the I/O Base Address
----------------------------
 
The first six switches in switch group SW1 are used to select one
of 32 possible I/O Base addresses using the following table
 
Switch | Hex I/O
6 5 4 3 2 1 | Address
-------------|--------
0 1 0 0 0 0 | 200
0 1 0 0 0 1 | 210
0 1 0 0 1 0 | 220
0 1 0 0 1 1 | 230
0 1 0 1 0 0 | 240
0 1 0 1 0 1 | 250
0 1 0 1 1 0 | 260
0 1 0 1 1 1 | 270
0 1 1 0 0 0 | 280
0 1 1 0 0 1 | 290
0 1 1 0 1 0 | 2A0
0 1 1 0 1 1 | 2B0
0 1 1 1 0 0 | 2C0
0 1 1 1 0 1 | 2D0
0 1 1 1 1 0 | 2E0 (Manufacturer's default)
0 1 1 1 1 1 | 2F0
1 1 0 0 0 0 | 300
1 1 0 0 0 1 | 310
1 1 0 0 1 0 | 320
1 1 0 0 1 1 | 330
1 1 0 1 0 0 | 340
1 1 0 1 0 1 | 350
1 1 0 1 1 0 | 360
1 1 0 1 1 1 | 370
1 1 1 0 0 0 | 380
1 1 1 0 0 1 | 390
1 1 1 0 1 0 | 3A0
1 1 1 0 1 1 | 3B0
1 1 1 1 0 0 | 3C0
1 1 1 1 0 1 | 3D0
1 1 1 1 1 0 | 3E0
1 1 1 1 1 1 | 3F0
 
 
Setting the Interrupt
---------------------
 
Switches seven through ten of switch group SW1 are used to select the
interrupt level. The interrupt level is binary coded, so selections
from 0 to 15 would be possible, but only the following eight values will
be supported: 3, 4, 5, 7, 9, 10, 11, 12.
 
Switch | IRQ
10 9 8 7 |
---------|--------
0 0 1 1 | 3
0 1 0 0 | 4
0 1 0 1 | 5
0 1 1 1 | 7
1 0 0 1 | 9 (=2) (default)
1 0 1 0 | 10
1 0 1 1 | 11
1 1 0 0 | 12
 
 
Setting the Timeouts
--------------------
 
The two jumpers JP2 (1-4) are used to determine the timeout parameters.
These two jumpers are normally left open.
Refer to the COM9026 Data Sheet for alternate configurations.
 
 
Configuring the PC500 for Star or Bus Topology
----------------------------------------------
 
The single jumper labeled JP6 is used to configure the PC500 board for
star or bus topology.
When the jumper is installed, the board may be used in a star network, when
it is removed, the board can be used in a bus topology.
 
 
Diagnostic LEDs
---------------
 
Two diagnostic LEDs are visible on the rear bracket of the board.
The green LED monitors the network activity: the red one shows the
board activity:
 
Green | Status Red | Status
-------|------------------- ---------|-------------------
on | normal activity flash/on | data transfer
blink | reconfiguration off | no data transfer;
off | defective board or | incorrect memory or
| node ID is zero | I/O address
 
 
*****************************************************************************
 
** SMC **
PC710 (8-bit card)
------------------
- from J.S. van Oosten <jvoosten@compiler.tdcnet.nl>
Note: this data is gathered by experimenting and looking at info of other
cards. However, I'm sure I got 99% of the settings right.
 
The SMC710 card resembles the PC270 card, but is much more basic (i.e. no
LEDs, RJ11 jacks, etc.) and 8 bit. Here's a little drawing:
 
_______________________________________
| +---------+ +---------+ |____
| | S2 | | S1 | |
| +---------+ +---------+ |
| |
| +===+ __ |
| | R | | | X-tal ###___
| | O | |__| ####__'|
| | M | || ###
| +===+ |
| |
| .. JP1 +----------+ |
| .. | big chip | |
| .. | 90C63 | |
| .. | | |
| .. +----------+ |
------- -----------
|||||||||||||||||||||
 
The row of jumpers at JP1 actually consists of 8 jumpers, (sometimes
labelled) the same as on the PC270, from top to bottom: EXT2, EXT1, ROM,
IRQ7, IRQ5, IRQ4, IRQ3, IRQ2 (gee, wonder what they would do? :-) )
 
S1 and S2 perform the same function as on the PC270, only their numbers
are swapped (S1 is the nodeaddress, S2 sets IO- and RAM-address).
 
I know it works when connected to a PC110 type ARCnet board.
 
*****************************************************************************
 
** Possibly SMC **
LCS-8830(-T) (8 and 16-bit cards)
---------------------------------
- from Mathias Katzer <mkatzer@HRZ.Uni-Bielefeld.DE>
- Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> says the
LCS-8830 is slightly different from LCS-8830-T. These are 8 bit, BUS
only (the JP0 jumper is hardwired), and BNC only.
This is a LCS-8830-T made by SMC, I think ('SMC' only appears on one PLCC,
nowhere else, not even on the few xeroxed sheets from the manual).
 
SMC Arcnet Board Type LCS-8830-T
 
------------------------------------
| |
| JP3 88 8 JP2 |
| ##### | \ |
| ##### ET1 ET2 ###|
| 8 ###|
| U3 SW 1 JP0 ###| Phone Jacks
| -- ###|
| | | |
| | | SW2 |
| | | |
| | | ##### |
| -- ##### #### BNC Connector
| ####
| 888888 JP1 |
| 234567 |
-- -------
|||||||||||||||||||||||||||
--------------------------
 
 
SW1: DIP-Switches for Station Address
SW2: DIP-Switches for Memory Base and I/O Base addresses
 
JP0: If closed, internal termination on (default open)
JP1: IRQ Jumpers
JP2: Boot-ROM enabled if closed
JP3: Jumpers for response timeout
U3: Boot-ROM Socket
 
 
ET1 ET2 Response Time Idle Time Reconfiguration Time
 
78 86 840
X 285 316 1680
X 563 624 1680
X X 1130 1237 1680
 
(X means closed jumper)
 
(DIP-Switch downwards means "0")
 
The station address is binary-coded with SW1.
 
The I/O base address is coded with DIP-Switches 6,7 and 8 of SW2:
 
Switches Base
678 Address
000 260-26f
100 290-29f
010 2e0-2ef
110 2f0-2ff
001 300-30f
101 350-35f
011 380-38f
111 3e0-3ef
 
 
DIP Switches 1-5 of SW2 encode the RAM and ROM Address Range:
 
Switches Ram Rom
12345 Address Range Address Range
00000 C:0000-C:07ff C:2000-C:3fff
10000 C:0800-C:0fff
01000 C:1000-C:17ff
11000 C:1800-C:1fff
00100 C:4000-C:47ff C:6000-C:7fff
10100 C:4800-C:4fff
01100 C:5000-C:57ff
11100 C:5800-C:5fff
00010 C:C000-C:C7ff C:E000-C:ffff
10010 C:C800-C:Cfff
01010 C:D000-C:D7ff
11010 C:D800-C:Dfff
00110 D:0000-D:07ff D:2000-D:3fff
10110 D:0800-D:0fff
01110 D:1000-D:17ff
11110 D:1800-D:1fff
00001 D:4000-D:47ff D:6000-D:7fff
10001 D:4800-D:4fff
01001 D:5000-D:57ff
11001 D:5800-D:5fff
00101 D:8000-D:87ff D:A000-D:bfff
10101 D:8800-D:8fff
01101 D:9000-D:97ff
11101 D:9800-D:9fff
00011 D:C000-D:c7ff D:E000-D:ffff
10011 D:C800-D:cfff
01011 D:D000-D:d7ff
11011 D:D800-D:dfff
00111 E:0000-E:07ff E:2000-E:3fff
10111 E:0800-E:0fff
01111 E:1000-E:17ff
11111 E:1800-E:1fff
 
 
*****************************************************************************
 
** PureData Corp **
PDI507 (8-bit card)
--------------------
- from Mark Rejhon <mdrejhon@magi.com> (slight modifications by Avery)
- Avery's note: I think PDI508 cards (but definitely NOT PDI508Plus cards)
are mostly the same as this. PDI508Plus cards appear to be mainly
software-configured.
 
Jumpers:
There is a jumper array at the bottom of the card, near the edge
connector. This array is labelled J1. They control the IRQs and
something else. Put only one jumper on the IRQ pins.
 
ETS1, ETS2 are for timing on very long distance networks. See the
more general information near the top of this file.
 
There is a J2 jumper on two pins. A jumper should be put on them,
since it was already there when I got the card. I don't know what
this jumper is for though.
 
There is a two-jumper array for J3. I don't know what it is for,
but there were already two jumpers on it when I got the card. It's
a six pin grid in a two-by-three fashion. The jumpers were
configured as follows:
 
.-------.
o | o o |
:-------: ------> Accessible end of card with connectors
o | o o | in this direction ------->
`-------'
 
Carl de Billy <CARL@carainfo.com> explains J3 and J4:
 
J3 Diagram:
 
.-------.
o | o o |
:-------: TWIST Technology
o | o o |
`-------'
.-------.
| o o | o
:-------: COAX Technology
| o o | o
`-------'
 
- If using coax cable in a bus topology the J4 jumper must be removed;
place it on one pin.
 
- If using bus topology with twisted pair wiring move the J3
jumpers so they connect the middle pin and the pins closest to the RJ11
Connectors. Also the J4 jumper must be removed; place it on one pin of
J4 jumper for storage.
 
- If using star topology with twisted pair wiring move the J3
jumpers so they connect the middle pin and the pins closest to the RJ11
connectors.
 
 
DIP Switches:
 
The DIP switches accessible on the accessible end of the card while
it is installed, is used to set the arcnet address. There are 8
switches. Use an address from 1 to 254.
 
Switch No.
12345678 Arcnet address
-----------------------------------------
00000000 FF (Don't use this!)
00000001 FE
00000010 FD
....
11111101 2
11111110 1
11111111 0 (Don't use this!)
 
There is another array of eight DIP switches at the top of the
card. There are five labelled MS0-MS4 which seem to control the
memory address, and another three labelled IO0-IO2 which seem to
control the base I/O address of the card.
 
This was difficult to test by trial and error, and the I/O addresses
are in a weird order. This was tested by setting the DIP switches,
rebooting the computer, and attempting to load ARCETHER at various
addresses (mostly between 0x200 and 0x400). The address that caused
the red transmit LED to blink, is the one that I thought works.
 
Also, the address 0x3D0 seem to have a special meaning, since the
ARCETHER packet driver loaded fine, but without the red LED
blinking. I don't know what 0x3D0 is for though. I recommend using
an address of 0x300 since Windows may not like addresses below
0x300.
 
IO Switch No.
210 I/O address
-------------------------------
111 0x260
110 0x290
101 0x2E0
100 0x2F0
011 0x300
010 0x350
001 0x380
000 0x3E0
 
The memory switches set a reserved address space of 0x1000 bytes
(0x100 segment units, or 4k). For example if I set an address of
0xD000, it will use up addresses 0xD000 to 0xD100.
 
The memory switches were tested by booting using QEMM386 stealth,
and using LOADHI to see what address automatically became excluded
from the upper memory regions, and then attempting to load ARCETHER
using these addresses.
 
I recommend using an arcnet memory address of 0xD000, and putting
the EMS page frame at 0xC000 while using QEMM stealth mode. That
way, you get contiguous high memory from 0xD100 almost all the way
the end of the megabyte.
 
Memory Switch 0 (MS0) didn't seem to work properly when set to OFF
on my card. It could be malfunctioning on my card. Experiment with
it ON first, and if it doesn't work, set it to OFF. (It may be a
modifier for the 0x200 bit?)
 
MS Switch No.
43210 Memory address
--------------------------------
00001 0xE100 (guessed - was not detected by QEMM)
00011 0xE000 (guessed - was not detected by QEMM)
00101 0xDD00
00111 0xDC00
01001 0xD900
01011 0xD800
01101 0xD500
01111 0xD400
10001 0xD100
10011 0xD000
10101 0xCD00
10111 0xCC00
11001 0xC900 (guessed - crashes tested system)
11011 0xC800 (guessed - crashes tested system)
11101 0xC500 (guessed - crashes tested system)
11111 0xC400 (guessed - crashes tested system)
*****************************************************************************
 
** CNet Technology Inc. **
120 Series (8-bit cards)
------------------------
- from Juergen Seifert <seifert@htwm.de>
 
 
CNET TECHNOLOGY INC. (CNet) ARCNET 120A SERIES
==============================================
 
This description has been written by Juergen Seifert <seifert@htwm.de>
using information from the following Original CNet Manual
 
"ARCNET
USER'S MANUAL
for
CN120A
CN120AB
CN120TP
CN120ST
CN120SBT
P/N:12-01-0007
Revision 3.00"
 
ARCNET is a registered trademark of the Datapoint Corporation
 
P/N 120A ARCNET 8 bit XT/AT Star
P/N 120AB ARCNET 8 bit XT/AT Bus
P/N 120TP ARCNET 8 bit XT/AT Twisted Pair
P/N 120ST ARCNET 8 bit XT/AT Star, Twisted Pair
P/N 120SBT ARCNET 8 bit XT/AT Star, Bus, Twisted Pair
 
__________________________________________________________________
| |
| ___|
| LED |___|
| ___|
| N | | ID7
| o | | ID6
| d | S | ID5
| e | W | ID4
| ___________________ A | 2 | ID3
| | | d | | ID2
| | | 1 2 3 4 5 6 7 8 d | | ID1
| | | _________________ r |___| ID0
| | 90C65 || SW1 | ____|
| JP 8 7 | ||_________________| | |
| |o|o| JP1 | | | J2 |
| |o|o| |oo| | | JP 1 1 1 | |
| ______________ | | 0 1 2 |____|
| | PROM | |___________________| |o|o|o| _____|
| > SOCKET | JP 6 5 4 3 2 |o|o|o| | J1 |
| |______________| |o|o|o|o|o| |o|o|o| |_____|
|_____ |o|o|o|o|o| ______________|
| |
|_____________________________________________|
 
Legend:
 
90C65 ARCNET Probe
S1 1-5: Base Memory Address Select
6-8: Base I/O Address Select
S2 1-8: Node ID Select (ID0-ID7)
JP1 ROM Enable Select
JP2 IRQ2
JP3 IRQ3
JP4 IRQ4
JP5 IRQ5
JP6 IRQ7
JP7/JP8 ET1, ET2 Timeout Parameters
JP10/JP11 Coax / Twisted Pair Select (CN120ST/SBT only)
JP12 Terminator Select (CN120AB/ST/SBT only)
J1 BNC RG62/U Connector (all except CN120TP)
J2 Two 6-position Telephone Jack (CN120TP/ST/SBT only)
 
Setting one of the switches to Off means "1", On means "0".
 
 
Setting the Node ID
-------------------
 
The eight switches in SW2 are used to set the node ID. Each node attached
to the network must have an unique node ID which must be different from 0.
Switch 1 (ID0) serves as the least significant bit (LSB).
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Label | Value
-------|-------|-------
1 | ID0 | 1
2 | ID1 | 2
3 | ID2 | 4
4 | ID3 | 8
5 | ID4 | 16
6 | ID5 | 32
7 | ID6 | 64
8 | ID7 | 128
 
Some Examples:
 
Switch | Hex | Decimal
8 7 6 5 4 3 2 1 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed
0 0 0 0 0 0 0 1 | 1 | 1
0 0 0 0 0 0 1 0 | 2 | 2
0 0 0 0 0 0 1 1 | 3 | 3
. . . | |
0 1 0 1 0 1 0 1 | 55 | 85
. . . | |
1 0 1 0 1 0 1 0 | AA | 170
. . . | |
1 1 1 1 1 1 0 1 | FD | 253
1 1 1 1 1 1 1 0 | FE | 254
1 1 1 1 1 1 1 1 | FF | 255
 
 
Setting the I/O Base Address
----------------------------
 
The last three switches in switch block SW1 are used to select one
of eight possible I/O Base addresses using the following table
 
 
Switch | Hex I/O
6 7 8 | Address
------------|--------
ON ON ON | 260
OFF ON ON | 290
ON OFF ON | 2E0 (Manufacturer's default)
OFF OFF ON | 2F0
ON ON OFF | 300
OFF ON OFF | 350
ON OFF OFF | 380
OFF OFF OFF | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer (RAM) requires 2K. The base of this buffer can be
located in any of eight positions. The address of the Boot Prom is
memory base + 8K or memory base + 0x2000.
Switches 1-5 of switch block SW1 select the Memory Base address.
 
Switch | Hex RAM | Hex ROM
1 2 3 4 5 | Address | Address *)
--------------------|---------|-----------
ON ON ON ON ON | C0000 | C2000
ON ON OFF ON ON | C4000 | C6000
ON ON ON OFF ON | CC000 | CE000
ON ON OFF OFF ON | D0000 | D2000 (Manufacturer's default)
ON ON ON ON OFF | D4000 | D6000
ON ON OFF ON OFF | D8000 | DA000
ON ON ON OFF OFF | DC000 | DE000
ON ON OFF OFF OFF | E0000 | E2000
*) To enable the Boot ROM install the jumper JP1
 
Note: Since the switches 1 and 2 are always set to ON it may be possible
that they can be used to add an offset of 2K, 4K or 6K to the base
address, but this feature is not documented in the manual and I
haven't tested it yet.
 
 
Setting the Interrupt Line
--------------------------
 
To select a hardware interrupt level install one (only one!) of the jumpers
JP2, JP3, JP4, JP5, JP6. JP2 is the default.
 
Jumper | IRQ
-------|-----
2 | 2
3 | 3
4 | 4
5 | 5
6 | 7
 
 
Setting the Internal Terminator on CN120AB/TP/SBT
--------------------------------------------------
 
The jumper JP12 is used to enable the internal terminator.
 
-----
0 | 0 |
----- ON | | ON
| 0 | | 0 |
| | OFF ----- OFF
| 0 | 0
-----
Terminator Terminator
disabled enabled
 
Selecting the Connector Type on CN120ST/SBT
-------------------------------------------
 
JP10 JP11 JP10 JP11
----- -----
0 0 | 0 | | 0 |
----- ----- | | | |
| 0 | | 0 | | 0 | | 0 |
| | | | ----- -----
| 0 | | 0 | 0 0
----- -----
Coaxial Cable Twisted Pair Cable
(Default)
 
 
Setting the Timeout Parameters
------------------------------
 
The jumpers labeled EXT1 and EXT2 are used to determine the timeout
parameters. These two jumpers are normally left open.
 
 
 
*****************************************************************************
 
** CNet Technology Inc. **
160 Series (16-bit cards)
-------------------------
- from Juergen Seifert <seifert@htwm.de>
 
CNET TECHNOLOGY INC. (CNet) ARCNET 160A SERIES
==============================================
 
This description has been written by Juergen Seifert <seifert@htwm.de>
using information from the following Original CNet Manual
 
"ARCNET
USER'S MANUAL
for
CN160A
CN160AB
CN160TP
P/N:12-01-0006
Revision 3.00"
 
ARCNET is a registered trademark of the Datapoint Corporation
 
P/N 160A ARCNET 16 bit XT/AT Star
P/N 160AB ARCNET 16 bit XT/AT Bus
P/N 160TP ARCNET 16 bit XT/AT Twisted Pair
 
___________________________________________________________________
< _________________________ ___|
> |oo| JP2 | | LED |___|
< |oo| JP1 | 9026 | LED |___|
> |_________________________| ___|
< N | | ID7
> 1 o | | ID6
< 1 2 3 4 5 6 7 8 9 0 d | S | ID5
> _______________ _____________________ e | W | ID4
< | PROM | | SW1 | A | 2 | ID3
> > SOCKET | |_____________________| d | | ID2
< |_______________| | IO-Base | MEM | d | | ID1
> r |___| ID0
< ____|
> | |
< | J1 |
> | |
< |____|
> 1 1 1 1 |
< 3 4 5 6 7 JP 8 9 0 1 2 3 |
> |o|o|o|o|o| |o|o|o|o|o|o| |
< |o|o|o|o|o| __ |o|o|o|o|o|o| ___________|
> | | |
<____________| |_______________________________________|
 
Legend:
 
9026 ARCNET Probe
SW1 1-6: Base I/O Address Select
7-10: Base Memory Address Select
SW2 1-8: Node ID Select (ID0-ID7)
JP1/JP2 ET1, ET2 Timeout Parameters
JP3-JP13 Interrupt Select
J1 BNC RG62/U Connector (CN160A/AB only)
J1 Two 6-position Telephone Jack (CN160TP only)
LED
 
Setting one of the switches to Off means "1", On means "0".
 
 
Setting the Node ID
-------------------
 
The eight switches in SW2 are used to set the node ID. Each node attached
to the network must have an unique node ID which must be different from 0.
Switch 1 (ID0) serves as the least significant bit (LSB).
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Label | Value
-------|-------|-------
1 | ID0 | 1
2 | ID1 | 2
3 | ID2 | 4
4 | ID3 | 8
5 | ID4 | 16
6 | ID5 | 32
7 | ID6 | 64
8 | ID7 | 128
 
Some Examples:
 
Switch | Hex | Decimal
8 7 6 5 4 3 2 1 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed
0 0 0 0 0 0 0 1 | 1 | 1
0 0 0 0 0 0 1 0 | 2 | 2
0 0 0 0 0 0 1 1 | 3 | 3
. . . | |
0 1 0 1 0 1 0 1 | 55 | 85
. . . | |
1 0 1 0 1 0 1 0 | AA | 170
. . . | |
1 1 1 1 1 1 0 1 | FD | 253
1 1 1 1 1 1 1 0 | FE | 254
1 1 1 1 1 1 1 1 | FF | 255
 
 
Setting the I/O Base Address
----------------------------
 
The first six switches in switch block SW1 are used to select the I/O Base
address using the following table:
 
Switch | Hex I/O
1 2 3 4 5 6 | Address
------------------------|--------
OFF ON ON OFF OFF ON | 260
OFF ON OFF ON ON OFF | 290
OFF ON OFF OFF OFF ON | 2E0 (Manufacturer's default)
OFF ON OFF OFF OFF OFF | 2F0
OFF OFF ON ON ON ON | 300
OFF OFF ON OFF ON OFF | 350
OFF OFF OFF ON ON ON | 380
OFF OFF OFF OFF OFF ON | 3E0
 
Note: Other IO-Base addresses seem to be selectable, but only the above
combinations are documented.
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The switches 7-10 of switch block SW1 are used to select the Memory
Base address of the RAM (2K) and the PROM.
 
Switch | Hex RAM | Hex ROM
7 8 9 10 | Address | Address
----------------|---------|-----------
OFF OFF ON ON | C0000 | C8000
OFF OFF ON OFF | D0000 | D8000 (Default)
OFF OFF OFF ON | E0000 | E8000
 
Note: Other MEM-Base addresses seem to be selectable, but only the above
combinations are documented.
 
 
Setting the Interrupt Line
--------------------------
 
To select a hardware interrupt level install one (only one!) of the jumpers
JP3 through JP13 using the following table:
 
Jumper | IRQ
-------|-----------------
3 | 14
4 | 15
5 | 12
6 | 11
7 | 10
8 | 3
9 | 4
10 | 5
11 | 6
12 | 7
13 | 2 (=9) Default!
 
Note: - Do not use JP11=IRQ6, it may conflict with your Floppy Disk
Controller
- Use JP3=IRQ14 only, if you don't have an IDE-, MFM-, or RLL-
Hard Disk, it may conflict with their controllers
 
 
Setting the Timeout Parameters
------------------------------
 
The jumpers labeled JP1 and JP2 are used to determine the timeout
parameters. These two jumpers are normally left open.
 
 
*****************************************************************************
 
** Lantech **
8-bit card, unknown model
-------------------------
- from Vlad Lungu <vlungu@ugal.ro> - his e-mail address seemed broken at
the time I tried to reach him. Sorry Vlad, if you didn't get my reply.
 
________________________________________________________________
| 1 8 |
| ___________ __|
| | SW1 | LED |__|
| |__________| |
| ___|
| _____________________ |S | 8
| | | |W |
| | | |2 |
| | | |__| 1
| | UM9065L | |o| JP4 ____|____
| | | |o| | CN |
| | | |________|
| | | |
| |___________________| |
| |
| |
| _____________ |
| | | |
| | PROM | |ooooo| JP6 |
| |____________| |ooooo| |
|_____________ _ _|
|____________________________________________| |__|
 
 
UM9065L : Arcnet Controller
 
SW 1 : Shared Memory Address and I/O Base
 
ON=0
 
12345|Memory Address
-----|--------------
00001| D4000
00010| CC000
00110| D0000
01110| D1000
01101| D9000
10010| CC800
10011| DC800
11110| D1800
 
It seems that the bits are considered in reverse order. Also, you must
observe that some of those addresses are unusual and I didn't probe them; I
used a memory dump in DOS to identify them. For the 00000 configuration and
some others that I didn't write here the card seems to conflict with the
video card (an S3 GENDAC). I leave the full decoding of those addresses to
you.
 
678| I/O Address
---|------------
000| 260
001| failed probe
010| 2E0
011| 380
100| 290
101| 350
110| failed probe
111| 3E0
 
SW 2 : Node ID (binary coded)
 
JP 4 : Boot PROM enable CLOSE - enabled
OPEN - disabled
 
JP 6 : IRQ set (ONLY ONE jumper on 1-5 for IRQ 2-6)
 
 
*****************************************************************************
 
** Acer **
8-bit card, Model 5210-003
--------------------------
- from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz> using portions of
the existing arcnet-hardware file.
 
This is a 90C26 based card. Its configuration seems similar to
the SMC PC100, but has some additional jumpers I don't know.
 
__
| |
___________|__|_________________________
| | | |
| | BNC | |
| |______| ___|
| _____________________ |___
| | | |
| | Hybrid IC | |
| | | o|o J1 |
| |_____________________| 8|8 |
| 8|8 J5 |
| o|o |
| 8|8 |
|__ 8|8 |
(|__| LED o|o |
| 8|8 |
| 8|8 J15 |
| |
| _____ |
| | | _____ |
| | | | | ___|
| | | | | |
| _____ | ROM | | UFS | |
| | | | | | | |
| | | ___ | | | | |
| | | | | |__.__| |__.__| |
| | NCR | |XTL| _____ _____ |
| | | |___| | | | | |
| |90C26| | | | | |
| | | | RAM | | UFS | |
| | | J17 o|o | | | | |
| | | J16 o|o | | | | |
| |__.__| |__.__| |__.__| |
| ___ |
| | |8 |
| |SW2| |
| | | |
| |___|1 |
| ___ |
| | |10 J18 o|o |
| | | o|o |
| |SW1| o|o |
| | | J21 o|o |
| |___|1 |
| |
|____________________________________|
 
 
Legend:
 
90C26 ARCNET Chip
XTL 20 MHz Crystal
SW1 1-6 Base I/O Address Select
7-10 Memory Address Select
SW2 1-8 Node ID Select (ID0-ID7)
J1-J5 IRQ Select
J6-J21 Unknown (Probably extra timeouts & ROM enable ...)
LED1 Activity LED
BNC Coax connector (STAR arcnet)
RAM 2k of SRAM
ROM Boot ROM socket
UFS Unidentified Flying Sockets
 
 
Setting the Node ID
-------------------
 
The eight switches in SW2 are used to set the node ID. Each node attached
to the network must have an unique node ID which must not be 0.
Switch 1 (ID0) serves as the least significant bit (LSB).
 
Setting one of the switches to OFF means "1", ON means "0".
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Value
-------|-------
1 | 1
2 | 2
3 | 4
4 | 8
5 | 16
6 | 32
7 | 64
8 | 128
 
Don't set this to 0 or 255; these values are reserved.
 
 
Setting the I/O Base Address
----------------------------
 
The switches 1 to 6 of switch block SW1 are used to select one
of 32 possible I/O Base addresses using the following tables
| Hex
Switch | Value
-------|-------
1 | 200
2 | 100
3 | 80
4 | 40
5 | 20
6 | 10
 
The I/O address is sum of all switches set to "1". Remember that
the I/O address space bellow 0x200 is RESERVED for mainboard, so
switch 1 should be ALWAYS SET TO OFF.
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer (RAM) requires 2K. The base of this buffer can be
located in any of sixteen positions. However, the addresses below
A0000 are likely to cause system hang because there's main RAM.
 
Jumpers 7-10 of switch block SW1 select the Memory Base address.
 
Switch | Hex RAM
7 8 9 10 | Address
----------------|---------
OFF OFF OFF OFF | F0000 (conflicts with main BIOS)
OFF OFF OFF ON | E0000
OFF OFF ON OFF | D0000
OFF OFF ON ON | C0000 (conflicts with video BIOS)
OFF ON OFF OFF | B0000 (conflicts with mono video)
OFF ON OFF ON | A0000 (conflicts with graphics)
 
 
Setting the Interrupt Line
--------------------------
 
Jumpers 1-5 of the jumper block J1 control the IRQ level. ON means
shorted, OFF means open.
 
Jumper | IRQ
1 2 3 4 5 |
----------------------------
ON OFF OFF OFF OFF | 7
OFF ON OFF OFF OFF | 5
OFF OFF ON OFF OFF | 4
OFF OFF OFF ON OFF | 3
OFF OFF OFF OFF ON | 2
 
 
Unknown jumpers & sockets
-------------------------
 
I know nothing about these. I just guess that J16&J17 are timeout
jumpers and maybe one of J18-J21 selects ROM. Also J6-J10 and
J11-J15 are connecting IRQ2-7 to some pins on the UFSs. I can't
guess the purpose.
 
 
*****************************************************************************
 
** Datapoint? **
LAN-ARC-8, an 8-bit card
------------------------
- from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
 
This is another SMC 90C65 based arcnet card. I couldn't identify the
manufacturer, but it might be DataPoint, because the card has the
original arcNet logo in its upper right corner.
 
_______________________________________________________
| _________ |
| | SW2 | ON arcNet |
| |_________| OFF ___|
| _____________ 1 ______ 8 | | 8
| | | SW1 | XTAL | ____________ | S |
| > RAM (2k) | |______|| | | W |
| |_____________| | H | | 3 |
| _________|_____ y | |___| 1
| _________ | | |b | |
| |_________| | | |r | |
| | SMC | |i | |
| | 90C65| |d | |
| _________ | | | | |
| | SW1 | ON | | |I | |
| |_________| OFF |_________|_____/C | _____|
| 1 8 | | | |___
| ______________ | | | BNC |___|
| | | |____________| |_____|
| > EPROM SOCKET | _____________ |
| |______________| |_____________| |
| ______________|
| |
|________________________________________|
 
Legend:
 
90C65 ARCNET Chip
SW1 1-5: Base Memory Address Select
6-8: Base I/O Address Select
SW2 1-8: Node ID Select
SW3 1-5: IRQ Select
6-7: Extra Timeout
8 : Rom Enable
BNC Coax connector
XTAL 20MHz Crystal
 
 
Setting the Node ID
-------------------
 
The eight switches in SW3 are used to set the node ID. Each node attached
to the network must have an unique node ID which must not be 0.
Switch 1 serves as the least significant bit (LSB).
 
Setting one of the switches to Off means "1", On means "0".
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Value
-------|-------
1 | 1
2 | 2
3 | 4
4 | 8
5 | 16
6 | 32
7 | 64
8 | 128
 
 
Setting the I/O Base Address
----------------------------
 
The last three switches in switch block SW1 are used to select one
of eight possible I/O Base addresses using the following table
 
 
Switch | Hex I/O
6 7 8 | Address
------------|--------
ON ON ON | 260
OFF ON ON | 290
ON OFF ON | 2E0 (Manufacturer's default)
OFF OFF ON | 2F0
ON ON OFF | 300
OFF ON OFF | 350
ON OFF OFF | 380
OFF OFF OFF | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer (RAM) requires 2K. The base of this buffer can be
located in any of eight positions. The address of the Boot Prom is
memory base + 0x2000.
Jumpers 3-5 of switch block SW1 select the Memory Base address.
 
Switch | Hex RAM | Hex ROM
1 2 3 4 5 | Address | Address *)
--------------------|---------|-----------
ON ON ON ON ON | C0000 | C2000
ON ON OFF ON ON | C4000 | C6000
ON ON ON OFF ON | CC000 | CE000
ON ON OFF OFF ON | D0000 | D2000 (Manufacturer's default)
ON ON ON ON OFF | D4000 | D6000
ON ON OFF ON OFF | D8000 | DA000
ON ON ON OFF OFF | DC000 | DE000
ON ON OFF OFF OFF | E0000 | E2000
*) To enable the Boot ROM set the switch 8 of switch block SW3 to position ON.
 
The switches 1 and 2 probably add 0x0800 and 0x1000 to RAM base address.
 
 
Setting the Interrupt Line
--------------------------
 
Switches 1-5 of the switch block SW3 control the IRQ level.
 
Jumper | IRQ
1 2 3 4 5 |
----------------------------
ON OFF OFF OFF OFF | 3
OFF ON OFF OFF OFF | 4
OFF OFF ON OFF OFF | 5
OFF OFF OFF ON OFF | 7
OFF OFF OFF OFF ON | 2
 
 
Setting the Timeout Parameters
------------------------------
 
The switches 6-7 of the switch block SW3 are used to determine the timeout
parameters. These two switches are normally left in the OFF position.
 
 
*****************************************************************************
 
** Topware **
8-bit card, TA-ARC/10
-------------------------
- from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
 
This is another very similar 90C65 card. Most of the switches and jumpers
are the same as on other clones.
 
_____________________________________________________________________
| ___________ | | ______ |
| |SW2 NODE ID| | | | XTAL | |
| |___________| | Hybrid IC | |______| |
| ___________ | | __|
| |SW1 MEM+I/O| |_________________________| LED1|__|)
| |___________| 1 2 |
| J3 |o|o| TIMEOUT ______|
| ______________ |o|o| | |
| | | ___________________ | RJ |
| > EPROM SOCKET | | \ |------|
|J2 |______________| | | | |
||o| | | |______|
||o| ROM ENABLE | SMC | _________ |
| _____________ | 90C65 | |_________| _____|
| | | | | | |___
| > RAM (2k) | | | | BNC |___|
| |_____________| | | |_____|
| |____________________| |
| ________ IRQ 2 3 4 5 7 ___________ |
||________| |o|o|o|o|o| |___________| |
|________ J1|o|o|o|o|o| ______________|
| |
|_____________________________________________|
 
Legend:
 
90C65 ARCNET Chip
XTAL 20 MHz Crystal
SW1 1-5 Base Memory Address Select
6-8 Base I/O Address Select
SW2 1-8 Node ID Select (ID0-ID7)
J1 IRQ Select
J2 Rom Enable
J3 Extra Timeout
LED1 Activity LED
BNC Coax connector (BUS arcnet)
RJ Twisted Pair Connector (daisychain)
 
 
Setting the Node ID
-------------------
 
The eight switches in SW2 are used to set the node ID. Each node attached to
the network must have an unique node ID which must not be 0. Switch 1 (ID0)
serves as the least significant bit (LSB).
 
Setting one of the switches to Off means "1", On means "0".
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Label | Value
-------|-------|-------
1 | ID0 | 1
2 | ID1 | 2
3 | ID2 | 4
4 | ID3 | 8
5 | ID4 | 16
6 | ID5 | 32
7 | ID6 | 64
8 | ID7 | 128
 
Setting the I/O Base Address
----------------------------
 
The last three switches in switch block SW1 are used to select one
of eight possible I/O Base addresses using the following table:
 
 
Switch | Hex I/O
6 7 8 | Address
------------|--------
ON ON ON | 260 (Manufacturer's default)
OFF ON ON | 290
ON OFF ON | 2E0
OFF OFF ON | 2F0
ON ON OFF | 300
OFF ON OFF | 350
ON OFF OFF | 380
OFF OFF OFF | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer (RAM) requires 2K. The base of this buffer can be
located in any of eight positions. The address of the Boot Prom is
memory base + 0x2000.
Jumpers 3-5 of switch block SW1 select the Memory Base address.
 
Switch | Hex RAM | Hex ROM
1 2 3 4 5 | Address | Address *)
--------------------|---------|-----------
ON ON ON ON ON | C0000 | C2000
ON ON OFF ON ON | C4000 | C6000 (Manufacturer's default)
ON ON ON OFF ON | CC000 | CE000
ON ON OFF OFF ON | D0000 | D2000
ON ON ON ON OFF | D4000 | D6000
ON ON OFF ON OFF | D8000 | DA000
ON ON ON OFF OFF | DC000 | DE000
ON ON OFF OFF OFF | E0000 | E2000
 
*) To enable the Boot ROM short the jumper J2.
 
The jumpers 1 and 2 probably add 0x0800 and 0x1000 to RAM address.
 
 
Setting the Interrupt Line
--------------------------
 
Jumpers 1-5 of the jumper block J1 control the IRQ level. ON means
shorted, OFF means open.
 
Jumper | IRQ
1 2 3 4 5 |
----------------------------
ON OFF OFF OFF OFF | 2
OFF ON OFF OFF OFF | 3
OFF OFF ON OFF OFF | 4
OFF OFF OFF ON OFF | 5
OFF OFF OFF OFF ON | 7
 
 
Setting the Timeout Parameters
------------------------------
 
The jumpers J3 are used to set the timeout parameters. These two
jumpers are normally left open.
 
*****************************************************************************
 
** Thomas-Conrad **
Model #500-6242-0097 REV A (8-bit card)
---------------------------------------
- from Lars Karlsson <100617.3473@compuserve.com>
 
________________________________________________________
| ________ ________ |_____
| |........| |........| |
| |________| |________| ___|
| SW 3 SW 1 | |
| Base I/O Base Addr. Station | |
| address | |
| ______ switch | |
| | | | |
| | | |___|
| | | ______ |___._
| |______| |______| ____| BNC
| Jumper- _____| Connector
| Main chip block _ __| '
| | | | RJ Connector
| |_| | with 110 Ohm
| |__ Terminator
| ___________ __|
| |...........| | RJ-jack
| |...........| _____ | (unused)
| |___________| |_____| |__
| Boot PROM socket IRQ-jumpers |_ Diagnostic
|________ __ _| LED (red)
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | |________|
|
|
 
And here are the settings for some of the switches and jumpers on the cards.
 
 
I/O
 
1 2 3 4 5 6 7 8
 
2E0----- 0 0 0 1 0 0 0 1
2F0----- 0 0 0 1 0 0 0 0
300----- 0 0 0 0 1 1 1 1
350----- 0 0 0 0 1 1 1 0
 
"0" in the above example means switch is off "1" means that it is on.
 
 
ShMem address.
 
1 2 3 4 5 6 7 8
 
CX00--0 0 1 1 | | |
DX00--0 0 1 0 |
X000--------- 1 1 |
X400--------- 1 0 |
X800--------- 0 1 |
XC00--------- 0 0
ENHANCED----------- 1
COMPATIBLE--------- 0
 
 
IRQ
 
 
3 4 5 7 2
. . . . .
. . . . .
 
 
There is a DIP-switch with 8 switches, used to set the shared memory address
to be used. The first 6 switches set the address, the 7th doesn't have any
function, and the 8th switch is used to select "compatible" or "enhanced".
When I got my two cards, one of them had this switch set to "enhanced". That
card didn't work at all, it wasn't even recognized by the driver. The other
card had this switch set to "compatible" and it behaved absolutely normally. I
guess that the switch on one of the cards, must have been changed accidently
when the card was taken out of its former host. The question remains
unanswered, what is the purpose of the "enhanced" position?
 
[Avery's note: "enhanced" probably either disables shared memory (use IO
ports instead) or disables IO ports (use memory addresses instead). This
varies by the type of card involved. I fail to see how either of these
enhance anything. Send me more detailed information about this mode, or
just use "compatible" mode instead.]
 
 
*****************************************************************************
 
** Waterloo Microsystems Inc. ?? **
8-bit card (C) 1985
-------------------
- from Robert Michael Best <rmb117@cs.usask.ca>
 
[Avery's note: these don't work with my driver for some reason. These cards
SEEM to have settings similar to the PDI508Plus, which is
software-configured and doesn't work with my driver either. The "Waterloo
chip" is a boot PROM, probably designed specifically for the University of
Waterloo. If you have any further information about this card, please
e-mail me.]
 
The probe has not been able to detect the card on any of the J2 settings,
and I tried them again with the "Waterloo" chip removed.
_____________________________________________________________________
| \/ \/ ___ __ __ |
| C4 C4 |^| | M || ^ ||^| |
| -- -- |_| | 5 || || | C3 |
| \/ \/ C10 |___|| ||_| |
| C4 C4 _ _ | | ?? |
| -- -- | \/ || | |
| | || | |
| | || C1 | |
| | || | \/ _____|
| | C6 || | C9 | |___
| | || | -- | BNC |___|
| | || | >C7| |_____|
| | || | |
| __ __ |____||_____| 1 2 3 6 |
|| ^ | >C4| |o|o|o|o|o|o| J2 >C4| |
|| | |o|o|o|o|o|o| |
|| C2 | >C4| >C4| |
|| | >C8| |
|| | 2 3 4 5 6 7 IRQ >C4| |
||_____| |o|o|o|o|o|o| J3 |
|_______ |o|o|o|o|o|o| _______________|
| |
|_____________________________________________|
 
C1 -- "COM9026
SMC 8638"
In a chip socket.
 
C2 -- "@Copyright
Waterloo Microsystems Inc.
1985"
In a chip Socket with info printed on a label covering a round window
showing the circuit inside. (The window indicates it is an EPROM chip.)
 
C3 -- "COM9032
SMC 8643"
In a chip socket.
 
C4 -- "74LS"
9 total no sockets.
 
M5 -- "50006-136
20.000000 MHZ
MTQ-T1-S3
0 M-TRON 86-40"
Metallic case with 4 pins, no socket.
 
C6 -- "MOSTEK@TC8643
MK6116N-20
MALAYSIA"
No socket.
 
C7 -- No stamp or label but in a 20 pin chip socket.
 
C8 -- "PAL10L8CN
8623"
In a 20 pin socket.
 
C9 -- "PAl16R4A-2CN
8641"
In a 20 pin socket.
 
C10 -- "M8640
NMC
9306N"
In an 8 pin socket.
 
?? -- Some components on a smaller board and attached with 20 pins all
along the side closest to the BNC connector. The are coated in a dark
resin.
 
On the board there are two jumper banks labeled J2 and J3. The
manufacturer didn't put a J1 on the board. The two boards I have both
came with a jumper box for each bank.
 
J2 -- Numbered 1 2 3 4 5 6.
4 and 5 are not stamped due to solder points.
J3 -- IRQ 2 3 4 5 6 7
 
The board itself has a maple leaf stamped just above the irq jumpers
and "-2 46-86" beside C2. Between C1 and C6 "ASS 'Y 300163" and "@1986
CORMAN CUSTOM ELECTRONICS CORP." stamped just below the BNC connector.
Below that "MADE IN CANADA"
 
*****************************************************************************
 
** No Name **
8-bit cards, 16-bit cards
-------------------------
- from Juergen Seifert <seifert@htwm.de>
NONAME 8-BIT ARCNET
===================
 
I have named this ARCnet card "NONAME", since there is no name of any
manufacturer on the Installation manual nor on the shipping box. The only
hint to the existence of a manufacturer at all is written in copper,
it is "Made in Taiwan"
 
This description has been written by Juergen Seifert <seifert@htwm.de>
using information from the Original
"ARCnet Installation Manual"
 
 
________________________________________________________________
| |STAR| BUS| T/P| |
| |____|____|____| |
| _____________________ |
| | | |
| | | |
| | | |
| | SMC | |
| | | |
| | COM90C65 | |
| | | |
| | | |
| |__________-__________| |
| _____|
| _______________ | CN |
| | PROM | |_____|
| > SOCKET | |
| |_______________| 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 |
| _______________ _______________ |
| |o|o|o|o|o|o|o|o| | SW1 || SW2 ||
| |o|o|o|o|o|o|o|o| |_______________||_______________||
|___ 2 3 4 5 7 E E R Node ID IOB__|__MEM____|
| \ IRQ / T T O |
|__________________1_2_M______________________|
 
Legend:
 
COM90C65: Arcnet Probe
S1 1-8: Node ID Select
S2 1-3: I/O Base Address Select
4-6: Memory Base Address Select
7-8: RAM Offset Select
ET1, ET2 Extended Timeout Select
ROM ROM Enable Select
CN RG62 Coax Connector
STAR| BUS | T/P Three fields for placing a sign (colored circle)
indicating the topology of the card
 
Setting one of the switches to Off means "1", On means "0".
 
 
Setting the Node ID
-------------------
 
The eight switches in group SW1 are used to set the node ID.
Each node attached to the network must have an unique node ID which
must be different from 0.
Switch 8 serves as the least significant bit (LSB).
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Value
-------|-------
8 | 1
7 | 2
6 | 4
5 | 8
4 | 16
3 | 32
2 | 64
1 | 128
 
Some Examples:
 
Switch | Hex | Decimal
1 2 3 4 5 6 7 8 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed
0 0 0 0 0 0 0 1 | 1 | 1
0 0 0 0 0 0 1 0 | 2 | 2
0 0 0 0 0 0 1 1 | 3 | 3
. . . | |
0 1 0 1 0 1 0 1 | 55 | 85
. . . | |
1 0 1 0 1 0 1 0 | AA | 170
. . . | |
1 1 1 1 1 1 0 1 | FD | 253
1 1 1 1 1 1 1 0 | FE | 254
1 1 1 1 1 1 1 1 | FF | 255
 
 
Setting the I/O Base Address
----------------------------
 
The first three switches in switch group SW2 are used to select one
of eight possible I/O Base addresses using the following table
 
Switch | Hex I/O
1 2 3 | Address
------------|--------
ON ON ON | 260
ON ON OFF | 290
ON OFF ON | 2E0 (Manufacturer's default)
ON OFF OFF | 2F0
OFF ON ON | 300
OFF ON OFF | 350
OFF OFF ON | 380
OFF OFF OFF | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer requires 2K of a 16K block of RAM. The base of this
16K block can be located in any of eight positions.
Switches 4-6 of switch group SW2 select the Base of the 16K block.
Within that 16K address space, the buffer may be assigned any one of four
positions, determined by the offset, switches 7 and 8 of group SW2.
 
Switch | Hex RAM | Hex ROM
4 5 6 7 8 | Address | Address *)
-----------|---------|-----------
0 0 0 0 0 | C0000 | C2000
0 0 0 0 1 | C0800 | C2000
0 0 0 1 0 | C1000 | C2000
0 0 0 1 1 | C1800 | C2000
| |
0 0 1 0 0 | C4000 | C6000
0 0 1 0 1 | C4800 | C6000
0 0 1 1 0 | C5000 | C6000
0 0 1 1 1 | C5800 | C6000
| |
0 1 0 0 0 | CC000 | CE000
0 1 0 0 1 | CC800 | CE000
0 1 0 1 0 | CD000 | CE000
0 1 0 1 1 | CD800 | CE000
| |
0 1 1 0 0 | D0000 | D2000 (Manufacturer's default)
0 1 1 0 1 | D0800 | D2000
0 1 1 1 0 | D1000 | D2000
0 1 1 1 1 | D1800 | D2000
| |
1 0 0 0 0 | D4000 | D6000
1 0 0 0 1 | D4800 | D6000
1 0 0 1 0 | D5000 | D6000
1 0 0 1 1 | D5800 | D6000
| |
1 0 1 0 0 | D8000 | DA000
1 0 1 0 1 | D8800 | DA000
1 0 1 1 0 | D9000 | DA000
1 0 1 1 1 | D9800 | DA000
| |
1 1 0 0 0 | DC000 | DE000
1 1 0 0 1 | DC800 | DE000
1 1 0 1 0 | DD000 | DE000
1 1 0 1 1 | DD800 | DE000
| |
1 1 1 0 0 | E0000 | E2000
1 1 1 0 1 | E0800 | E2000
1 1 1 1 0 | E1000 | E2000
1 1 1 1 1 | E1800 | E2000
*) To enable the 8K Boot PROM install the jumper ROM.
The default is jumper ROM not installed.
 
 
Setting Interrupt Request Lines (IRQ)
-------------------------------------
 
To select a hardware interrupt level set one (only one!) of the jumpers
IRQ2, IRQ3, IRQ4, IRQ5 or IRQ7. The manufacturer's default is IRQ2.
 
Setting the Timeouts
--------------------
 
The two jumpers labeled ET1 and ET2 are used to determine the timeout
parameters (respons and reconfiguration time). Every node in a network
must be set to the same timeout values.
 
ET1 ET2 | Response Time (us) | Reconfiguration Time (ms)
--------|--------------------|--------------------------
Off Off | 78 | 840 (Default)
Off On | 285 | 1680
On Off | 563 | 1680
On On | 1130 | 1680
 
On means jumper installed, Off means jumper not installed
 
 
NONAME 16-BIT ARCNET
====================
 
The manual of my 8-Bit NONAME ARCnet Card contains another description
of a 16-Bit Coax / Twisted Pair Card. This description is incomplete,
because there are missing two pages in the manual booklet. (The table
of contents reports pages ... 2-9, 2-11, 2-12, 3-1, ... but inside
the booklet there is a different way of counting ... 2-9, 2-10, A-1,
(empty page), 3-1, ..., 3-18, A-1 (again), A-2)
Also the picture of the board layout is not as good as the picture of
8-Bit card, because there isn't any letter like "SW1" written to the
picture.
Should somebody have such a board, please feel free to complete this
description or to send a mail to me!
 
This description has been written by Juergen Seifert <seifert@htwm.de>
using information from the Original
"ARCnet Installation Manual"
 
 
___________________________________________________________________
< _________________ _________________ |
> | SW? || SW? | |
< |_________________||_________________| |
> ____________________ |
< | | |
> | | |
< | | |
> | | |
< | | |
> | | |
< | | |
> |____________________| |
< ____|
> ____________________ | |
< | | | J1 |
> | < | |
< |____________________| ? ? ? ? ? ? |____|
> |o|o|o|o|o|o| |
< |o|o|o|o|o|o| |
> |
< __ ___________|
> | | |
<____________| |_______________________________________|
 
 
Setting one of the switches to Off means "1", On means "0".
 
 
Setting the Node ID
-------------------
 
The eight switches in group SW2 are used to set the node ID.
Each node attached to the network must have an unique node ID which
must be different from 0.
Switch 8 serves as the least significant bit (LSB).
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Value
-------|-------
8 | 1
7 | 2
6 | 4
5 | 8
4 | 16
3 | 32
2 | 64
1 | 128
 
Some Examples:
 
Switch | Hex | Decimal
1 2 3 4 5 6 7 8 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed
0 0 0 0 0 0 0 1 | 1 | 1
0 0 0 0 0 0 1 0 | 2 | 2
0 0 0 0 0 0 1 1 | 3 | 3
. . . | |
0 1 0 1 0 1 0 1 | 55 | 85
. . . | |
1 0 1 0 1 0 1 0 | AA | 170
. . . | |
1 1 1 1 1 1 0 1 | FD | 253
1 1 1 1 1 1 1 0 | FE | 254
1 1 1 1 1 1 1 1 | FF | 255
 
 
Setting the I/O Base Address
----------------------------
 
The first three switches in switch group SW1 are used to select one
of eight possible I/O Base addresses using the following table
 
Switch | Hex I/O
3 2 1 | Address
------------|--------
ON ON ON | 260
ON ON OFF | 290
ON OFF ON | 2E0 (Manufacturer's default)
ON OFF OFF | 2F0
OFF ON ON | 300
OFF ON OFF | 350
OFF OFF ON | 380
OFF OFF OFF | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer requires 2K of a 16K block of RAM. The base of this
16K block can be located in any of eight positions.
Switches 6-8 of switch group SW1 select the Base of the 16K block.
Within that 16K address space, the buffer may be assigned any one of four
positions, determined by the offset, switches 4 and 5 of group SW1.
 
Switch | Hex RAM | Hex ROM
8 7 6 5 4 | Address | Address
-----------|---------|-----------
0 0 0 0 0 | C0000 | C2000
0 0 0 0 1 | C0800 | C2000
0 0 0 1 0 | C1000 | C2000
0 0 0 1 1 | C1800 | C2000
| |
0 0 1 0 0 | C4000 | C6000
0 0 1 0 1 | C4800 | C6000
0 0 1 1 0 | C5000 | C6000
0 0 1 1 1 | C5800 | C6000
| |
0 1 0 0 0 | CC000 | CE000
0 1 0 0 1 | CC800 | CE000
0 1 0 1 0 | CD000 | CE000
0 1 0 1 1 | CD800 | CE000
| |
0 1 1 0 0 | D0000 | D2000 (Manufacturer's default)
0 1 1 0 1 | D0800 | D2000
0 1 1 1 0 | D1000 | D2000
0 1 1 1 1 | D1800 | D2000
| |
1 0 0 0 0 | D4000 | D6000
1 0 0 0 1 | D4800 | D6000
1 0 0 1 0 | D5000 | D6000
1 0 0 1 1 | D5800 | D6000
| |
1 0 1 0 0 | D8000 | DA000
1 0 1 0 1 | D8800 | DA000
1 0 1 1 0 | D9000 | DA000
1 0 1 1 1 | D9800 | DA000
| |
1 1 0 0 0 | DC000 | DE000
1 1 0 0 1 | DC800 | DE000
1 1 0 1 0 | DD000 | DE000
1 1 0 1 1 | DD800 | DE000
| |
1 1 1 0 0 | E0000 | E2000
1 1 1 0 1 | E0800 | E2000
1 1 1 1 0 | E1000 | E2000
1 1 1 1 1 | E1800 | E2000
 
Setting Interrupt Request Lines (IRQ)
-------------------------------------
 
??????????????????????????????????????
 
 
Setting the Timeouts
--------------------
 
??????????????????????????????????????
 
 
*****************************************************************************
 
** No Name **
8-bit cards ("Made in Taiwan R.O.C.")
-----------
- from Vojtech Pavlik <Vojtech.Pavlik@st.mff.cuni.cz>
 
I have named this ARCnet card "NONAME", since I got only the card with
no manual at all and the only text identifying the manufacturer is
"MADE IN TAIWAN R.O.C" printed on the card.
 
____________________________________________________________
| 1 2 3 4 5 6 7 8 |
| |o|o| JP1 o|o|o|o|o|o|o|o| ON |
| + o|o|o|o|o|o|o|o| ___|
| _____________ o|o|o|o|o|o|o|o| OFF _____ | | ID7
| | | SW1 | | | | ID6
| > RAM (2k) | ____________________ | H | | S | ID5
| |_____________| | || y | | W | ID4
| | || b | | 2 | ID3
| | || r | | | ID2
| | || i | | | ID1
| | 90C65 || d | |___| ID0
| SW3 | || | |
| |o|o|o|o|o|o|o|o| ON | || I | |
| |o|o|o|o|o|o|o|o| | || C | |
| |o|o|o|o|o|o|o|o| OFF |____________________|| | _____|
| 1 2 3 4 5 6 7 8 | | | |___
| ______________ | | | BNC |___|
| | | |_____| |_____|
| > EPROM SOCKET | |
| |______________| |
| ______________|
| |
|_____________________________________________|
 
Legend:
 
90C65 ARCNET Chip
SW1 1-5: Base Memory Address Select
6-8: Base I/O Address Select
SW2 1-8: Node ID Select (ID0-ID7)
SW3 1-5: IRQ Select
6-7: Extra Timeout
8 : Rom Enable
JP1 Led connector
BNC Coax connector
 
Although the jumpers SW1 and SW3 are marked SW, not JP, they are jumpers, not
switches.
 
Setting the jumpers to ON means connecting the upper two pins, off the bottom
two - or - in case of IRQ setting, connecting none of them at all.
 
Setting the Node ID
-------------------
 
The eight switches in SW2 are used to set the node ID. Each node attached
to the network must have an unique node ID which must not be 0.
Switch 1 (ID0) serves as the least significant bit (LSB).
 
Setting one of the switches to Off means "1", On means "0".
 
The node ID is the sum of the values of all switches set to "1"
These values are:
 
Switch | Label | Value
-------|-------|-------
1 | ID0 | 1
2 | ID1 | 2
3 | ID2 | 4
4 | ID3 | 8
5 | ID4 | 16
6 | ID5 | 32
7 | ID6 | 64
8 | ID7 | 128
 
Some Examples:
 
Switch | Hex | Decimal
8 7 6 5 4 3 2 1 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed
0 0 0 0 0 0 0 1 | 1 | 1
0 0 0 0 0 0 1 0 | 2 | 2
0 0 0 0 0 0 1 1 | 3 | 3
. . . | |
0 1 0 1 0 1 0 1 | 55 | 85
. . . | |
1 0 1 0 1 0 1 0 | AA | 170
. . . | |
1 1 1 1 1 1 0 1 | FD | 253
1 1 1 1 1 1 1 0 | FE | 254
1 1 1 1 1 1 1 1 | FF | 255
 
 
Setting the I/O Base Address
----------------------------
 
The last three switches in switch block SW1 are used to select one
of eight possible I/O Base addresses using the following table
 
 
Switch | Hex I/O
6 7 8 | Address
------------|--------
ON ON ON | 260
OFF ON ON | 290
ON OFF ON | 2E0 (Manufacturer's default)
OFF OFF ON | 2F0
ON ON OFF | 300
OFF ON OFF | 350
ON OFF OFF | 380
OFF OFF OFF | 3E0
 
 
Setting the Base Memory (RAM) buffer Address
--------------------------------------------
 
The memory buffer (RAM) requires 2K. The base of this buffer can be
located in any of eight positions. The address of the Boot Prom is
memory base + 0x2000.
Jumpers 3-5 of jumper block SW1 select the Memory Base address.
 
Switch | Hex RAM | Hex ROM
1 2 3 4 5 | Address | Address *)
--------------------|---------|-----------
ON ON ON ON ON | C0000 | C2000
ON ON OFF ON ON | C4000 | C6000
ON ON ON OFF ON | CC000 | CE000
ON ON OFF OFF ON | D0000 | D2000 (Manufacturer's default)
ON ON ON ON OFF | D4000 | D6000
ON ON OFF ON OFF | D8000 | DA000
ON ON ON OFF OFF | DC000 | DE000
ON ON OFF OFF OFF | E0000 | E2000
*) To enable the Boot ROM set the jumper 8 of jumper block SW3 to position ON.
 
The jumpers 1 and 2 probably add 0x0800, 0x1000 and 0x1800 to RAM adders.
 
Setting the Interrupt Line
--------------------------
 
Jumpers 1-5 of the jumper block SW3 control the IRQ level.
 
Jumper | IRQ
1 2 3 4 5 |
----------------------------
ON OFF OFF OFF OFF | 2
OFF ON OFF OFF OFF | 3
OFF OFF ON OFF OFF | 4
OFF OFF OFF ON OFF | 5
OFF OFF OFF OFF ON | 7
 
 
Setting the Timeout Parameters
------------------------------
 
The jumpers 6-7 of the jumper block SW3 are used to determine the timeout
parameters. These two jumpers are normally left in the OFF position.
 
 
*****************************************************************************
 
** No Name **
(Generic Model 9058)
--------------------
- from Andrew J. Kroll <ag784@freenet.buffalo.edu>
- Sorry this sat in my to-do box for so long, Andrew! (yikes - over a
year!)
_____
| <
| .---'
________________________________________________________________ | |
| | SW2 | | |
| ___________ |_____________| | |
| | | 1 2 3 4 5 6 ___| |
| > 6116 RAM | _________ 8 | | |
| |___________| |20MHzXtal| 7 | | |
| |_________| __________ 6 | S | |
| 74LS373 | |- 5 | W | |
| _________ | E |- 4 | | |
| >_______| ______________|..... P |- 3 | 3 | |
| | | : O |- 2 | | |
| | | : X |- 1 |___| |
| ________________ | | : Y |- | |
| | SW1 | | SL90C65 | : |- | |
| |________________| | | : B |- | |
| 1 2 3 4 5 6 7 8 | | : O |- | |
| |_________o____|..../ A |- _______| |
| ____________________ | R |- | |------,
| | | | D |- | BNC | # |
| > 2764 PROM SOCKET | |__________|- |_______|------'
| |____________________| _________ | |
| >________| <- 74LS245 | |
| | |
|___ ______________| |
|H H H H H H H H H H H H H H H H H H H H H H H| | |
|U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U_U| | |
\|
Legend:
 
SL90C65 ARCNET Controller / Transceiver /Logic
SW1 1-5: IRQ Select
6: ET1
7: ET2
8: ROM ENABLE
SW2 1-3: Memory Buffer/PROM Address
3-6: I/O Address Map
SW3 1-8: Node ID Select
BNC BNC RG62/U Connection
*I* have had success using RG59B/U with *NO* terminators!
What gives?!
 
SW1: Timeouts, Interrupt and ROM
---------------------------------
 
To select a hardware interrupt level set one (only one!) of the dip switches
up (on) SW1...(switches 1-5)
IRQ3, IRQ4, IRQ5, IRQ7, IRQ2. The Manufacturer's default is IRQ2.
 
The switches on SW1 labeled EXT1 (switch 6) and EXT2 (switch 7)
are used to determine the timeout parameters. These two dip switches
are normally left off (down).
 
To enable the 8K Boot PROM position SW1 switch 8 on (UP) labeled ROM.
The default is jumper ROM not installed.
 
 
Setting the I/O Base Address
----------------------------
 
The last three switches in switch group SW2 are used to select one
of eight possible I/O Base addresses using the following table
 
 
Switch | Hex I/O
4 5 6 | Address
-------|--------
0 0 0 | 260
0 0 1 | 290
0 1 0 | 2E0 (Manufacturer's default)
0 1 1 | 2F0
1 0 0 | 300
1 0 1 | 350
1 1 0 | 380
1 1 1 | 3E0
 
 
Setting the Base Memory Address (RAM & ROM)
-------------------------------------------
 
The memory buffer requires 2K of a 16K block of RAM. The base of this
16K block can be located in any of eight positions.
Switches 1-3 of switch group SW2 select the Base of the 16K block.
(0 = DOWN, 1 = UP)
I could, however, only verify two settings...
 
Switch| Hex RAM | Hex ROM
1 2 3 | Address | Address
------|---------|-----------
0 0 0 | E0000 | E2000
0 0 1 | D0000 | D2000 (Manufacturer's default)
0 1 0 | ????? | ?????
0 1 1 | ????? | ?????
1 0 0 | ????? | ?????
1 0 1 | ????? | ?????
1 1 0 | ????? | ?????
1 1 1 | ????? | ?????
 
 
Setting the Node ID
-------------------
 
The eight switches in group SW3 are used to set the node ID.
Each node attached to the network must have an unique node ID which
must be different from 0.
Switch 1 serves as the least significant bit (LSB).
switches in the DOWN position are OFF (0) and in the UP position are ON (1)
 
The node ID is the sum of the values of all switches set to "1"
These values are:
Switch | Value
-------|-------
1 | 1
2 | 2
3 | 4
4 | 8
5 | 16
6 | 32
7 | 64
8 | 128
 
Some Examples:
 
Switch# | Hex | Decimal
8 7 6 5 4 3 2 1 | Node ID | Node ID
----------------|---------|---------
0 0 0 0 0 0 0 0 | not allowed <-.
0 0 0 0 0 0 0 1 | 1 | 1 |
0 0 0 0 0 0 1 0 | 2 | 2 |
0 0 0 0 0 0 1 1 | 3 | 3 |
. . . | | |
0 1 0 1 0 1 0 1 | 55 | 85 |
. . . | | + Don't use 0 or 255!
1 0 1 0 1 0 1 0 | AA | 170 |
. . . | | |
1 1 1 1 1 1 0 1 | FD | 253 |
1 1 1 1 1 1 1 0 | FE | 254 |
1 1 1 1 1 1 1 1 | FF | 255 <-'
 
*****************************************************************************
 
** Tiara **
(model unknown)
-------------------------
- from Christoph Lameter <clameter@netcom.com>
 
Here is information about my card as far as I could figure it out:
----------------------------------------------- tiara
Tiara LanCard of Tiara Computer Systems.
 
+----------------------------------------------+
! ! Transmitter Unit ! !
! +------------------+ -------
! MEM Coax Connector
! ROM 7654321 <- I/O -------
! : : +--------+ !
! : : ! 90C66LJ! +++
! : : ! ! !D Switch to set
! : : ! ! !I the Nodenumber
! : : +--------+ !P
! !++
! 234567 <- IRQ !
+------------!!!!!!!!!!!!!!!!!!!!!!!!--------+
!!!!!!!!!!!!!!!!!!!!!!!!
 
0 = Jumper Installed
1 = Open
 
Top Jumper line Bit 7 = Rom Enable 654=Memory location 321=I/O
 
Settings for Memory Location (Top Jumper Line)
456 Address selected
000 C0000
001 C4000
010 CC000
011 D0000
100 D4000
101 D8000
110 DC000
111 E0000
 
Settings for I/O Address (Top Jumper Line)
123 Port
000 260
001 290
010 2E0
011 2F0
100 300
101 350
110 380
111 3E0
 
Settings for IRQ Selection (Lower Jumper Line)
234567
011111 IRQ 2
101111 IRQ 3
110111 IRQ 4
111011 IRQ 5
111110 IRQ 7
 
*****************************************************************************
 
 
Other Cards
-----------
 
I have no information on other models of ARCnet cards at the moment. Please
send any and all info to:
apenwarr@foxnet.net
 
Thanks.
/soundmodem.txt
0,0 → 1,96
LINUX DRIVER FOR SOUNDCARDS AS AX.25 MODEMS
 
Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
 
This driver allows either SoundBlaster (sbc) or WindowsSoundSystem (wss)
compatible soundcards to be used as either 1200 baud AFSK or 9600 baud FSK
AX.25 packet radio modems. Only half duplex operation is supported by
the SoundBlaster driver. Fullduplex is supported for WSS chipsets capable
of addressing two DMA channels. The driver needs some processing power!
A 486DX/2 66MHz is a minimum requirement, otherwise interactive performance
of the computer may become sluggish.
 
 
The Interface of the driver
 
The driver provides a kernel network drivers named sm[0-3]. sethdlc
from the ax25 utilities may be used to set driver states etc. Users
of userland AX.25 stacks may use the net2kiss utility (also available
in the ax25 utilities package) to converts packets of a network interface
to a KISS stream on a pseudo tty. There's also a patch available from
me for WAMPES which allows attaching a kernel network interface directly.
 
 
Configuring the driver
 
Some sound cards need to be initialized before they operate in either
SoundBlaster or WSS compatibility mode. The driver does _NOT_ do this;
you may use the standard linux sound driver to initialize the soundcard;
compile it as a module, and do
insmod sound
rmmod sound
The soundcard should then be initialized correctly. isapnptools is another
package that can configure PnP soundcards. If your soundcard contains
a Crystal CS423x chip, you may also try the setcrystal utility in the
ax25-utilities package.
 
Every time the driver is inserted into the kernel, it has to know which
modems it should access at which ports. This can be done with the sethdlc
utility. If you are only using one modem, you can also configure the
driver from the insmod command line (or by means of an option line in
/etc/conf.modules).
 
Examples: (use either method, not both)
insmod soundmodem mode="sbc:afsk1200" iobase=0x220 irq=5 dma=1
sethdlc -i sm0 -p hw sbc type afsk1200 io 0x220 irq 5 dma 1
 
Both lines configure the first port to drive a soundblaster card
in 1200 baud AFSK mode.
 
The channel access parameters can be set with sethdlc -a or kissparms.
Note that both utilities interpret the values slightly different.
 
 
Input and output levels
 
It is important that the input and output levels are adjusted properly.
There are two utilities, available in the ax25 utilities distribution,
to facilitate this: smmixer and smdiag. smdiag allows you to display
the input signal in an oscilloscope like display or an eye diagram.
smmixer allows you to adjust input/output levels. See the respective
man pages. These two utilities have two counterparts: xfsmmixer and
xfsmdiag. They both require the FORMS to compile, and provide a nicer
user interface. Functionality is the same, though.
 
 
Transmitter keying
 
Since soundcards do not have a DC coupled output; PTT keying options include
the following:
* VOX circuitry
* Serial port pin
* Parallel port pin
* MPU401 MIDI output via a retriggerable monoflop.
Circuit schematics may be found at
http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html.
 
 
Compatibility with the rest of the Linux kernel
 
The sound driver and the soundcard modem driver compete for the same
hardware resources. Of course only one driver can access a given
interface at a time. Worse yet, the sound driver grabs the soundcard
at startup time. Therefore the soundcard modem driver subsequently won't
be able to access the soundcard. You might therefore find it necessary to
unload the sound driver before using the soundcard modem driver.
 
 
Further reading
 
Please take a look at http://www.ife.ee.ethz.ch/~sailer/ham/linux/hdlc.html
for further informations on the driver.
 
 
vy 73s de
Tom Sailer, sailer@ife.ee.ethz.ch
Packet Radio: hb9jnx@hb9w.che.eu
/baycom.txt
0,0 → 1,131
LINUX DRIVER FOR BAYCOM MODEMS
 
Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
 
This document describes the Linux Kernel Driver for simple Baycom style
amateur radio modems. The driver supports the following modems:
 
ser12: This is a very simple 1200 baud AFSK modem. The modem consists only
of a modulator/demodulator chip, usually a TI TCM3105. The computer
is responsible for regenerating the receiver bit clock, as well as
for handling the HDLC protocol. The modem connects to a serial port,
hence the name. Since the serial port is not used as an async serial
port, the kernel driver for serial ports cannot be used, and this
driver only supports standard serial hardware (8250, 16450, 16550)
 
par96: This is a modem for 9600 baud FSK compatible to the G3RUH standard.
The modem does all the filtering and regenerates the receiver clock.
Data is transferred from and to the PC via a shift register.
The shift register is filled with 16 bits and an interrupt is signalled.
The PC then empties the shift register in a burst. This modem connects
to the parallel port, hence the name. The modem leaves the
implementation of the HDLC protocol and the scrambler polynomial to
the PC.
 
picpar: This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
is protocol compatible to par96, but uses only three low power ICs
and can therefore be fed from the parallel port and does not require
an additional power supply. Furthermore, it incorporates a carrier
detect circuitry.
 
All of the above modems only support half duplex communications. However,
the driver supports the KISS (see below) fullduplex command. It then simply
starts to send as soon as there's a packet to transmit and does not care
about DCD, i.e. it starts to send even if there's someone else on the channel.
This command is required by some implementations of the DAMA channel
access protocol.
 
 
The Interface of the driver
 
Unlike previous drivers, the driver is no longer a character device,
but it is now a true kernel network interface. Installation is therefore
simple. Once installed, four interfaces named bc[0-3] are available.
sethdlc from the ax25 utilities may be used to set driver states etc.
Users of userland AX.25 stacks may use the net2kiss utility (also available
in the ax25 utilities package) to converts packets of a network interface
to a KISS stream on a pseudo tty. There's also a patch available from
me for WAMPES which allows attaching a kernel network interface directly.
 
 
Configuring the driver
 
Every time the driver is inserted into the kernel, it has to know which
modems it should access at which ports. This can be done with the setbaycom
utility. If you are only using one modem, you can also configure the
driver from the insmod command line (or by means of an option line in
/etc/conf.modules).
 
Examples: (use either method, not both)
insmod baycom mode="ser12*" iobase=0x3f8 irq=4
sethdlc -i bc0 -p type "ser12*" io 0x3f8 irq 4
 
Both lines configure the first port to drive a ser12 modem at the first
serial port (COM1 under DOS). The star ('*') instructs the driver to use
the software DCD algorithm (see below).
 
insmod baycom mode="par96*" iobase=0x378 irq=7
sethdlc -i bc0 -p type "par96*" io 0x378 irq 7
 
Both lines configure the first port to drive a par96 or par97 modem at the
first parallel port (LPT1 under DOS). options=1 instructs the driver to use
the software DCD algorithm (see below).
insmod baycom mode="par96" iobase=0x278 irq=5
sethdlc -i bc0 -p type "par96" io 0x278 irq 5
 
Both lines configure the first port to drive a picpar modem at the
second parallel port (LPT2 under DOS). The driver uses the hardware DCD
signalled by the picpar modem (see below).
The channel access parameters can be set with sethdlc -a or kissparms.
Note that both utilities interpret the values slightly different.
 
 
 
Hardware DCD versus Software DCD
 
To avoid collisions on the air, the driver must know when the channel is
busy. This is the task of the DCD circuitry/software. The driver may either
utilise a software DCD algorithm (a star after the mode string) or use a DCD
signal from the hardware (no star).
 
ser12: if software DCD is utilised, the radio's squelch should always be
open. It is highly recommended to use the software DCD algorithm,
as it is much faster than most hardware squelch circuitry. The
disadvantage is a slightly higher load on the system.
 
par96: the software DCD algorithm for this type of modem is rather poor.
The modem simply does not provide enough information to implement
a reasonable DCD algorithm in software. Therefore, if your radio
feeds the DCD input of the par96 modem, the use of the hardware
DCD circuitry is recommended.
 
picpar: the picpar modem features a builtin DCD hardware, which is highly
recommended.
 
 
 
Compatibility with the rest of the Linux kernel
 
The serial driver, the line printer (lp) driver and the baycom driver compete
for the same hardware resources. Of course only one driver can access a given
interface at a time. The serial driver grabs all interfaces it can find at
startup time. Therefore the baycom driver subsequently won't be able to
access a serial port. You might therefore find it necessary to release
a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
# is the number of the interface. The baycom driver does not reserve any
port at startup, unless one is specified on the 'insmod' command line. Another
method to solve the problem is to compile all three drivers as modules and
leave it to kerneld to load the correct driver depending on the application.
 
 
Further reading
 
Please take a look at http://www.ife.ee.ethz.ch/~sailer/ham/linux/hdlc.html
for further informations on the driver.
 
 
vy 73s de
Tom Sailer, sailer@ife.ee.ethz.ch
Packet Radio: hb9jnx@hb9w.che.eu
/tlan.README
0,0 → 1,135
TLAN driver for Linux, version 1.0
README
 
Well, I'm back. The TLAN driver seems pretty stable, so I'm
declaring this cycle of development finished, and calling the
driver 1.0. I will, of course continue to work on improving
the driver, and work towards a 2.0 release.
 
 
 
I. Supported Devices.
 
Only PCI devices will work with this driver.
 
Supported:
Vendor ID Device ID Name
0e11 ae32 Compaq Netelligent 10/100 TX PCI UTP
0e11 ae34 Compaq Netelligent 10 T PCI UTP
0e11 ae35 Compaq Integrated NetFlex 3/P
0e11 ae40 Compaq Netelligent Dual 10/100 TX PCI UTP
0e11 ae43 Compaq Netelligent Integrated 10/100 TX UTP
0e11 b011 Compaq Netelligent 10/100 TX Embedded UTP
0e11 b012 Compaq Netelligent 10 T/2 PCI UTP/Coax
0e11 b030 Compaq Netelligent 10/100 TX UTP
0e11 f130 Compaq NetFlex 3/P
0e11 f150 Compaq NetFlex 3/P
108d 0012 Olicom OC-2325
108d 0013 Olicom OC-2183
108d 0014 Olicom OC-2326
 
 
Caveats:
I am not sure if 100BaseTX daughterboards (for those cards which
support such things) will work. I haven't had any solid evidence
either way.
 
However, if a card supports 100BaseTx without requiring an add
on daughterboard, it should work with 100BaseTx.
 
The "Netelligent 10 T/2 PCI UTP/Coax" (b012) device is untested,
but I do not expect any problems.
 
II. Building the Driver.
 
The TLAN driver may be compiled into the kernel, or it may be compiled
as a module separately, or in the kernel. A patch is included for
2.0.29 (which also works for 2.0.30, 2.0.31, and 2.0.32).
 
To compile it as part of the kernel:
1. Download and untar the TLAN driver package.
2. If your kernel is 2.1.45 or later, you do not need to patch the
kernel sources. Copy the tlan.c and tlan.h to drivers/net in
the kernel source tree.
3. Otherwise, apply the appropriate patch for your kernel. For
example:
 
cd /usr/src/linux
patch -p1 < kernel.2.0.29
 
4. Copy the files tlan.c and tlan.h from the TLAN package to the
directory drivers/net in the Linux kernel source tree.
5. Configure your kernel for the TLAN driver. Answer 'Y' when
prompted to ask about experimental code (the first question).
Then answer 'Y' when prompted if to include TI ThunderLAN
support. If you want the driver compiled as a module, answer 'M'
instead of 'Y'.
6. Make the kernel and, if necessary, the modules.
To compile the TLAN driver independently:
1. Download and untar the TLAN driver package.
2. Change to the tlan directory.
3. If you are NOT using a versioned kernel (ie, want an non-
versioned module), edit the Makefile, and comment out the
line:
MODVERSIONS = -DMODVERSIONS
4. Run 'make'.
 
 
III. Driver Options
1. You can append debug=x to the end of the insmod line to get
debug messages, where x is a bit field where the bits mean
the following:
0x01 Turn on general debugging messages.
0x02 Turn on receive debugging messages.
0x04 Turn on transmit debugging messages.
0x08 Turn on list debugging messsages.
 
2. You can append aui=1 to the end of the insmod line to cause
the adapter to use the AUI interface instead of the 10 Base T
interface. This is also what to do if you want to use the BNC
connector on a TLAN based device. (Setting this option on a
device that does not have an AUI/BNC connector will probably
cause it to not function correctly.)
 
4. You can set duplex=1 to force half duplex, and duplex=2 to
force full duplex.
 
5. You can set speed=10 to force 10Mbs operation, and speed=100Mbs
to force 100Mbs operation. (I'm not sure what will happen
if a card which only supports 10Mbs is forced into 100Mbs
mode.)
 
3. If the driver is built into the kernel, you can use the 3rd
and 4th parameters to set aui and debug respectively. For
example:
 
ether=0,0,0x1,0x7,eth0
 
This sets aui to 0x1 and debug to 0x7, assuming eth0 is a
supported TLAN device.
 
The bits in the third byte are assigned as follows:
 
0x01 = aui
0x02 = use SA_INTERRUPT flag when reserving the irq.
0x04 = use half duplex
0x08 = use full duplex
0x10 = use 10BaseT
0x20 = use 100BaseTx
 
 
IV. Things to try if you have problems.
1. Make sure your card's PCI id is among those listed in
section I, above.
1. Make sure routing is correct.
2. If you are using a 2.1.x kernel, try to duplicate the
problem on a 2.0.x (preferably 2.0.29 or 2.0.30) kernel.
 
 
There is also a tlan mailing list which you can join by sending "subscribe tlan"
in the body of an email to majordomo@vuser.vu.union.edu.
 
/arcnet.txt
0,0 → 1,483
 
----------------------------------------------------------------------------
NOTE: See also arcnet-hardware.txt in this directory for jumper-setting
and cabling information if you're like many of us and didn't happen to get a
manual with your ARCnet card.
----------------------------------------------------------------------------
 
Since no one seems to listen to me otherwise, perhaps a poem will get your
attention:
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 two
lines. 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 if
you 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 was
nice, but after that even FEWER people started writing to me because they
didn'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 to
start 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 also
include the type of card(s) you're using, software, size of network, and
whether it's working or not.)
 
My e-mail address is: apenwarr@foxnet.net
 
 
---------------------------------------------------------------------------
 
These are the ARCnet drivers for Linux.
 
This new release has resulted from many months of on-and-off effort from me
(Avery Pennarun), many bug reports/fixes and suggestions from others, and in
particular a lot of input and coding from Tomasz Motylewski. Starting with
ARCnet 2.10 ALPHA, Tomasz's all-new-and-improved RFC1051 support has been
included and seems to be working fine!
 
 
Where do I discuss these drivers?
---------------------------------
 
Tomasz Motylewski 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 YOUR REAL NAME" to listserv@tichy.ch.uj.edu.pl. Then, to
submit messages to the list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
 
There are archives of the mailing list at:
http://tichy.ch.uj.edu.pl/lists/linux-arcnet
 
The people on linux-net@vger.rutgers.edu have also been known to be very
helpful, especially when we're talking about ALPHA Linux kernels that may or
may not work right in the first place.
 
 
Other Drivers and Info
----------------------
 
You can try my ARCNET page on the World Wide Web at:
http://www.foxnet.net/~apenwarr/arcnet/
 
Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
might be interested in, which includes several drivers for various cards
including ARCnet. Try:
http://www.smc.com/
Performance Technologies makes various network software that supports
ARCnet:
http://www.perftech.com/ or ftp to ftp.perftech.com.
Novell makes a networking stack for DOS which includes ARCnet drivers. Try
ftp'ing to ftp.novell.com.
 
You can get the Crynwr packet driver collection (including arcether.com, the
one you'll want to use with arcnet cards) from
oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
without patches, though, and also doesn't like several cards. Fixed
versions are available on my WWW page, or via e-mail if you don't have WWW
access.
 
 
Installing the Driver
---------------------
 
If this driver was included as part of your Linux kernel source, all you
will need to do in order to install it is:
make config
(be sure to choose ARCnet under "other ISA cards")
make dep
make clean
make zImage
If you obtained this ARCnet package as an upgrade to the ARCnet driver in
your current kernel, you will need to first copy arcnet.c over the one in
the linux/drivers/net directory.
 
You will know the driver is installed properly if you get a lot of ARCnet
messages when you boot into the new Linux kernel. (These messages can be
disabled by taking D_INIT out of the list of debug flags in arcnet.c.)
 
 
Loadable Module Support
-----------------------
 
Configure and rebuild Linux. When asked, answer 'm' to "arcnet support" if
you want to use the loadable module.
 
make config
make dep
make clean
make zImage
make modules
If you're using a loadable module, you need to use insmod to load it, and
you can specify various characteristics of your card on the command
line. (In recent versions of the driver, autoprobing is much more reliable
and works as a module, so most of this is now unnecessary.)
 
For example:
cd /usr/src/linux/modules
insmod arcnet.o io=0x300 irq=2 shmem=0xd0000
 
You can name the device using something like "device=arc1" (for a second
card) or "device=eth0" (for weird compatibility reasons) if you like.
 
Using the Driver
----------------
 
If you build your kernel with ARCnet support included, it should probe for
your card automatically when you boot.
 
Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
available where you picked up this driver. Think of your ARCnet as a
souped-up (or down, as the case may be) Ethernet card.
 
By the way, be sure to change all references from "eth0" to "arc0" in the
HOWTOs. Remember that ARCnet isn't a "true" Ethernet, and the device name
is DIFFERENT.
 
 
Multiple Cards in One Computer
------------------------------
 
Linux has pretty good support for this now, but since I've been busy, the
ARCnet driver has somewhat suffered in this respect. For now, the easiest
way to use multiple ARCnet cards is to build it as a loadable module and
then do something like this:
insmod -o arc0 arcnet
insmod -o arc1 arcnet device=arc1
(Note that in the first line, the default is device=arc0, but it doesn't
hurt if you want to add it for consistency.)
 
 
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. There
is also a DOS-based NFS server called SOSS. It doesn't multitask
quite the way Linux does (actually, it doesn't multitask AT ALL) but
you never know what you might need.
With AmiTCP (and possibly others), you may need to set the following
options 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. I
don't know why the defaults on the Amiga didn't work; write to me if
you know more.
 
DOS: If you're using the freeware arcether.com, you might want to install
the driver patch from my web page. It helps with PC/TCP, and also
can get arcether to load if it timed out too quickly during
initialization. In fact, if you use it on a 386+ you REALLY need
the patch, really.
Windows: See DOS :) Trumpet Winsock works fine with either the Novell or
Arcether client, assuming you remember to load winpkt of course.
 
LAN Manager and Windows for Workgroups: These programs use protocols that
are incompatible with the internet standard. They try to pretend
the cards are Ethernet, and confuse everyone else on the network.
However, v2.00 and higher of the Linux ARCnet driver supports this
protocol via the 'arc0e' device. See the section on "Multiprotocol
Support" for more information.
 
Using the freeware Samba server and clients for Linux, you can now
interface quite nicely with TCP/IP-based WfWg or Lan Manager
networks.
Windows 95: Tools are included with Win95 that let you use either the LANMAN
style network drivers (NDIS) or Novell drivers (ODI) to handle your
ARCnet 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 of
hybrid network that uses both encapsulation types.
 
OS2: I've been told it works under Warp Connect with an ARCnet driver from
SMC. You need to use the 'arc0e' interface for this. If you get
the 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" client
which should use the same protocol as WfWg does. I had no luck
installing it under Warp, however. Please mail me with any results.
 
NetBSD/AmiTCP: These use an old version of the Internet standard ARCnet
protocol (RFC1051) which is compatible with the Linux driver v2.10
ALPHA 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 just
happens to be 100% compatible with Novell's TRXNET driver.
Version 1.00 of the ARCnet driver supported _only_ this
protocol. arc0 is the fastest of the three protocols (for
whatever reason), and allows larger packets to be used
because 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 ARCnet
that are actually a lot like Ethernet packets, including the
6-byte hardware addresses. This protocol is compatible with
Microsoft's NDIS ARCnet driver, like the one in WfWg and
LANMAN. Because the MTU of 493 is actually smaller than the
one "required" by TCP/IP (576), there is a chance that some
network operations will not function properly. The Linux
TCP/IP layer can compensate in most cases, however, by
automatically fragmenting the TCP/IP packets to make them
fit. arc0e also works slightly more slowly than arc0, for
reasons yet to be determined. (Probably it's the smaller
MTU that does it.)
arc0s - The "[s]imple" RFC1051 protocol is the "previous" internet
standard that is completely incompatible with the new
standard. Some software today, however, continues to
support the old standard (and only the old standard)
including NetBSD and AmiTCP. RFC1051 also does not support
RFC1201's packet splitting, and the MTU of 507 is still
smaller than the internet "requirement," so it's quite
possible that you may run into problems. It's also slower
than RFC1201 by about 25%, for the same reason as arc0e.
The arc0s support was contributed by Tomasz Motylewski
and 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 to
use the "NFS-root" stuff in recent Linux kernels.
 
The arc0e and arc0s devices are created automatically when you first
ifconfig the arc0 device. To actually use them, though, you need to also
ifconfig the other virtual devices you need. There are a number of ways you
can set up your network then:
 
 
1. Single Protocol.
 
This is the simplest way to configure your network: use just one of the
two available protocols. As mentioned above, it's a good idea to use
only 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.RESS
route add MY.IP.ADD.RESS arc0
route 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.RESS
ifconfig arc0e MY.IP.ADD.RESS
route add MY.IP.ADD.RESS arc0e
route add -net SUB.NET.ADD.RESS arc0e
arc0s works much the same way as arc0e.
 
 
2. More than one protocol on the same wire.
 
Now things start getting confusing. To even try it, you may need to be
partly crazy. Here's what *I* did. :) Note that I don't include arc0s in
my home network; I don't have any NetBSD or AmiTCP computers, so I only
use arc0s during limited testing.
 
I have three computers on my home network; two Linux boxes (which prefer
RFC1201 protocol, for reasons listed above), and one XT that can't run
Linux but runs the free Microsoft LANMAN Client instead.
 
Worse, one of the Linux computers (freedom) also has a modem and acts as
a router to my internet provider. The other Linux box (insight) also has
its own IP address and needs to use freedom as its default gateway. The
XT (patience), however, does not have its own internet IP address and so
I 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 it
more and it's faster.
- use freedom as its internet gateway.
That's pretty easy to do. Set up insight like this:
ifconfig arc0 insight
route add insight arc0
route add freedom arc0 /* I would use the subnet here (like I said
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 freedom
route add freedom arc0
route add insight arc0
/* and default gateway is configured by pppd */
Great, now insight talks to freedom directly on arc0, and sends packets
to 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 gets
worse.
 
Now, how do I add patience into the network? It will be using LANMAN
Client, which means I need the arc0e device. It needs to be able to talk
to both insight and freedom, and also use freedom as a gateway to the
internet. (Recall that patience has a "private IP address" which won't
work on the internet; that's okay, I configured Linux IP masquerading on
freedom for this subnet).
So patience (necessarily; I don't have another IP number from my
provider) has an IP address on a different subnet than freedom and
insight, but needs to use freedom as an internet gateway. Worse, most
DOS networking programs, including LANMAN, have braindead networking
schemes that rely completely on the netmask and a 'default gateway' to
determine how to route packets. This means that to get to freedom or
insight, patience WILL send through its default gateway, regardless of
the 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. I
then define gatekeeper to be the default gateway for patience.
To configure freedom (in addition to the commands above):
ifconfig arc0e gatekeeper
route add gatekeeper arc0e
route 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 it
talks to insight or the internet, it will use its "freedom" internet IP
address.
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 to
assign insight another special IP number from my private subnet. Since
both insight and patience are using freedom as their default gateway, the
two can already talk to each other.
It's quite fortunate that I set things up like this the first time (cough
cough) because it's really handy when I boot insight into DOS. There, it
runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet.
In this mode it would be impossible for insight to communicate directly
with patience, since the Novell stack is incompatible with Microsoft's
Ethernet-Encap. Without changing any settings on freedom or patience, I
simply set freedom as the default gateway for insight (now in DOS,
remember) and all the forwarding happens "automagically" between the two
hosts that would normally not be able to communicate at all.
For those who like diagrams, I have created two "virtual subnets" on the
same 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, kernel
version, ARCnet card model, CPU type, number of systems on your network, and
list of software in use to me at the following address:
apenwarr@foxnet.net
 
I do send (sometimes automated) replies to all messages I receive. My email
can be weird (and also usually gets forwarded all over the place along the
way to me), so if you don't get a reply within a reasonable time, please
resend.
 
 
It doesn't work: what now?
--------------------------
 
Do the same as above, but also include the output of the ifconfig and route
commands, as well as any pertinent log entries (ie. anything that starts
with "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 me
about the problem first, since it might already have been solved) you may
want to try some of the debug levels available. For heavy testing on
D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
first! 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 changed
significantly. In particular, they won't tell you why the card was not
found unless you turn on the D_INIT_REASONS debugging flag.
 
Once the driver is running, you can run the arcdump shell script (available
from me or in the full ARCnet package, if you have it) as root to list the
contents of the arcnet buffers at any time. To make any sense at all out of
this, you should grab the pertinent RFC's. (some are listed near the top of
arcnet.c). arcdump assumes your card is at 0xD0000. If it isn't, edit the
script.
 
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 is
reset (which should only happen when you do an ifconfig up, or when Linux
decides that the driver is broken). During a transmit, unused parts of the
buffer will be cleared to 0x42 as well. This is to make it easier to figure
out 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 put
you at debug level 15. Debug level 7 is currently the default.
 
Note that the debug level is (starting with v1.90 ALPHA) a binary
combination of different debug flags; so debug level 7 is really 1+2+4 or
D_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.
/depca.txt
0,0 → 1,92
 
DE10x
=====
 
Memory Addresses:
 
SW1 SW2 SW3 SW4
64K on on on on d0000 dbfff
off on on on c0000 cbfff
off off on on e0000 ebfff
 
32K on on off on d8000 dbfff
off on off on c8000 cbfff
off off off on e8000 ebfff
 
DBR ROM on on dc000 dffff
off on cc000 cffff
off off ec000 effff
 
Note that the 2K mode is set by SW3/SW4 on/off or off/off. Address
assignment is through the RBSA register.
 
I/O Address:
SW5
0x300 on
0x200 off
 
Remote Boot:
SW6
Disable on
Enable off
 
Remote Boot Timeout:
SW7
2.5min on
30s off
 
IRQ:
SW8 SW9 SW10 SW11 SW12
2 on off off off off
3 off on off off off
4 off off on off off
5 off off off on off
7 off off off off on
 
DE20x
=====
 
Memory Size:
 
SW3 SW4
64K on on
32K off on
2K on off
2K off off
 
Start Addresses:
 
SW1 SW2 SW3 SW4
64K on on on on c0000 cffff
on off on on d0000 dffff
off on on on e0000 effff
 
32K on on off off c8000 cffff
on off off off d8000 dffff
off on off off e8000 effff
 
Illegal off off - - - -
 
I/O Address:
SW5
0x300 on
0x200 off
 
Remote Boot:
SW6
Disable on
Enable off
 
Remote Boot Timeout:
SW7
2.5min on
30s off
 
IRQ:
SW8 SW9 SW10 SW11 SW12
5 on off off off off
9 off on off off off
10 off off on off off
11 off off off on off
15 off off off off on
 
/ip_dynaddr.txt
0,0 → 1,54
IP dynamic address hack-port v0.03-rst
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This stuff allows diald ONESHOT connections to get established by
dynamically changing packet source address (and socket's if local procs).
It is implemented for TCP diald-box connections(1) and IP_MASQuerading(2).
 
If enabled[*] and forwarding interface address has changed:
1) Socket (and packet) source address is rewritten ON RETRANSMISSIONS
while in SYN_SENT state (diald-box processes).
2) Out-bounded MASQueraded source address changes ON OUTPUT (when
internal host does retransmission) until a packet from outside is
received by the tunnel.
 
This is specially helpful for auto dialup links (diald), where the
``actual'' outgoing address is unknown at the moment the link is
going up. So, the *same* (local AND masqueraded) connections requests that
bring the link up will be able to get established.
 
If you enable the RST-provoking mode, then the source address will
be changed, even if the socket is established. This means we send
an incorrect packet out, which causes the remote host to kill our
socket. This is the desired behaviour, because such a socket is
doomed anyway, and the earlier it dies, the better. This prevents
the dial-on-demand connection from being kept up by a dead connection,
and tells the application that the connection was lost.
 
[*] At boot, by default no address rewriting is attempted.
 
The values for the ip_dynaddr sysctl are:
 
1: To enable:
2: To enable verbosity:
4: To enable RST-provoking:
 
Flags can be combined by adding them. Common settings
would be:
 
To switch off special handling of dynamic addresses (default)
# echo 0 > /proc/sys/net/ipv4/ip_dynaddr
To enable rewriting in quiet mode:
# echo 1 > /proc/sys/net/ipv4/ip_dynaddr
To enable rewriting in verbose mode:
# echo 3 > /proc/sys/net/ipv4/ip_dynaddr
(for backwards compatibility you can also use)
# echo 2 > /proc/sys/net/ipv4/ip_dynaddr
To enable quiet RST-provoking mode:
# echo 5 > /proc/sys/net/ipv4/ip_dynaddr
To enable verbose RST-provoking mode:
# echo 7 > /proc/sys/net/ipv4/ip_dynaddr
 
Enjoy!
 
-- Juanjo <jjciarla@raiz.uncu.edu.ar>
(with RST-provoking mode by Erik Corry <erik@arbat.com>)
/ax25.txt
0,0 → 1,16
To use the amateur radio protocols within Linux you will need to get a
suitable copy of the AX.25 Utilities. More detailed information about these
and associated programs can be found on http://www.cs.nott.ac.uk/~jsn/.
 
For more information about the AX.25, NET/ROM and ROSE protocol stacks, see
the AX25-HOWTO written by Terry Dawson <terry@perf.no.itg.telstra.com.au>
who is also the AX.25 Utilities maintainer.
 
There is an active mailing list for discussing Linux amateur radio matters
called linux-hams. To subscribe to it, send a message to
Majordomo@vger.rutgers.edu with the words "subscribe linux-hams" in the body
of the message, the subject field is ignored.
 
Jonathan G4KLX
 
jsn@cs.nott.ac.uk
/masquerading.txt
0,0 → 1,51
IP Masquerading lets you run multiple machines on a network behind a
Linux box so that all the machines (including the Linux masquerade box)
appear as a single IP address to the outside world.
 
The main use of masquerading is when your ISP only gives you one IP
address and wants to charge like a wounded bull for multiple IP
addresses. Instead of paying your ISP large amounts of money for a
separate address for each of your machines, funnel them all through a
Linux box running IP masquerading. Even when you have multiple IP
addresses, you can still use masquerading if you want to hide your
internal networks from the rest of the world.
 
To activate IP masquerading, compile the kernel with IP Forwarding, IP
Firewalling and IP Masquerading, the first two options must be on
before you can see the masquerade option. Also consider using the
ipautofw and ICMP masquerading suboptions.
 
Some of the masq code is in the kernel, some is in modules so you have
to make zImage and make modules. There are masq helper modules to
handle special protocols, you only need to load a helper module if you
want to use the corresponding protocol. Helper modules have to be
explicitly loaded (usually from somewhere in /etc/rc.d), they cannot be
loaded using kerneld. The current helper modules are ip_masq_ftp,
ip_masq_irc, ip_masq_raudio, ip_masq_cuseeme, ip_masq_vdolive,
ip_masq_quake.
 
All of the modules can take a parameter specifying the port they work
on - ie ftp handles connections to port 21 by default. This parameter,
which can be ommitted to take the default port(s) makes the command
line look like this
insmod ip_masq_raudio.o ports=7070,7071,7072
Up to 12 ports can be specified (this value can be changed if you
recompile).
 
Masquerading is more of a server function than a single user function.
Using it correctly requires some knowledge of TCP, UDP, IP and a high
level understanding of some protocols. For more details on IP
masquerading, visit
http://www.indyramp.com/masq/
and read the HOWTO.
 
There is a mailing list covering use of masqueraing, information can
be found on the indyramp web site given above - please read the basic
information before posting to the mailing list.
 
Other information on masquerading can be found at
http://www.wwonline.com/~achau/ipmasq/
 
March 5, 1997
Keith Owens
Nigel Metheringham
/shaper.txt
0,0 → 1,49
Traffic Shaper For Linux
 
This is the current ALPHA release of the traffic shaper for Linux. It works
within the following limits:
 
o Minimum shaping speed is currently about 9600 baud (it can only
shape down to 1 byte per clock tick)
 
o Maximum is about 256K, it will go above this but get a bit blocky.
 
o If you ifconfig the master device that a shaper is attached to down
then your machine will follow.
 
o The shaper must be a module.
 
 
Setup:
 
A shaper device is configured using the shapeconfig program.
Typically you will do something like this
 
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
ifconfig shaper0 myhost netmask 255.255.255.240 broadcast 1.2.3.4.255 up
route add -net some.network netmask a.b.c.d dev shaper0
 
The shaper should have the same IP address as the device it is attached to
for normal use.
 
Gotchas:
 
The shaper shapes transmitted traffic. It's rather impossible to
shape received traffic except at the end (or a router) transmitting it.
 
Gated/routed/rwhod/mrouted all see the shaper as an additional device
and will treat it as such unless patched. Note that for mrouted you can run
mrouted tunnels via a traffic shaper to control bandwidth usage.
 
The shaper is device/route based. This makes it very easy to use
with any setup BUT less flexible. You may well want to combine this patch
with Mike McLagan <mmclagan@linux.org>'s patch to allow routes to be
specified by source/destination pairs.
 
There is no "borrowing" or "sharing" scheme. This is a simple
traffic limiter. I'd like to implement Van Jacobson and Sally Floyd's CBQ
architecture into Linux one day (maybe in 2.1 sometime) and do this with
style.
 
Alan
/Configurable
0,0 → 1,33
 
There are a few network parameters that can be tuned to better match
the kernel to your system hardware and intended usage. The defaults
are usually a good choice for 99% of the people 99% of the time, but
you should be aware they do exist and can be changed.
 
The current list of parameters can be found in the file:
 
./linux/net/TUNABLE
 
Some of these are accessible via the sysctl interface, and many more are
scheduled to be added in this way. For example, some parameters related
to Address Resolution Protocol (ARP) are very easily viewed and altered.
 
# cat /proc/sys/net/ipv4/arp_timeout
6000
# echo 7000 > /proc/sys/net/ipv4/arp_timeout
# cat /proc/sys/net/ipv4/arp_timeout
7000
 
Others are already accessible via the related user space programs.
For example, MAX_WINDOW has a default of 32k which is a good choice for
modern hardware, but if you have a slow (8 bit) ethercard and/or a slow
machine, then this will be far too big for the card to keep up with fast
Tx'ing machines on the same net, resulting in overruns and receive errors.
A value of about 4k would be more appropriate, which can be set via:
 
# route add -net 192.168.3.0 window 4096
 
The remainder of these can only be presently changed by altering a #define
in the related header file. This means an edit and recompile cycle.
 
Paul Gortmaker 06/96
/tlan.FAQ
0,0 → 1,28
1. Q. Ifconfig reports "10Mbs Ethernet" for my 10/100Mbs card. How do
I get my card to run in 100Mbs mode?
 
A. The "10Mbs Ethernet" is poorly named. What this is really saying
is that this device is some kind of Ethernet device (ie, uses
ethernet style frames at the link layer). Recent versions of
ifconfig report this as simply "Ethernet".
 
The TLAN driver is designed to autodetect 10Mbs vs. 100Mbs
connections, and choose the higher speed. The most sure way
to determine what speed you are running at is to look at the
100Mbs LED on the card, if your device has one.
 
 
2. Q. My network card is using the same interrupt as my SCSI card.
 
A. Some Compaqs set all PCI devices to the same interrupt by default.
You can either change the interrupt used by one of the device
with your Compaq configuration utility, or you can have the TLAN
driver use the same type of interrupt handler:
 
a. For module based use, add 'sa_int=1' to the command line, eg.:
insmod tlan.o sa_int=1
 
b. For compiled in kernel, set the 0x2 bit in the third part
for the boot parameter for that device, eg.:
ether=0,0,0x2,0,eth0
 
/tcp.txt
0,0 → 1,39
How the new TCP output machine [nyi] works.
 
 
Data is kept on a single queue. The skb->users flag tells us if the frame is
one that has been queued already. To add a frame we throw it on the end. Ack
walks down the list from the start.
 
We keep a set of control flags
 
 
sk->tcp_pend_event
 
TCP_PEND_ACK Ack needed
TCP_ACK_NOW Needed now
TCP_WINDOW Window update check
TCP_WINZERO Zero probing
 
 
sk->transmit_queue The transmission frame begin
sk->transmit_new First new frame pointer
sk->transmit_end Where to add frames
 
sk->tcp_last_tx_ack Last ack seen
sk->tcp_dup_ack Dup ack count for fast retransmit
 
 
Frames are queued for output by tcp_write. We do our best to send the frames
off immediately if possible, but otherwise queue and compute the body
checksum in the copy.
 
When a write is done we try to clear any pending events and piggy back them.
If the window is full we queue full sized frames. On the first timeout in
zero window we split this.
 
On a timer we walk the retransmit list to send any retransmits, update the
backoff timers etc. A change of route table stamp causes a change of header
and recompute. We add any new tcp level headers and refinish the checksum
before sending.
 
/framerelay.txt
0,0 → 1,39
Frame Relay (FR) support for linux is built into a two tiered system of device
drivers. The upper layer implements RFC1490 FR specification, and uses the
Data Link Connection Identifier (DLCI) as its hardware address. Usually these
are assigned by your network supplier, they give you the number/numbers of
the Virtual Connections (VC) assigned to you.
 
Each DLCI is a point-to-point link between your machine and a remote one.
As such, a separate device is needed to accommodate the routing. Within the
net-tools archives is 'dlcicfg'. This program will communicate with the
base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'...
The configuration script will ask you how many DLCI's you need, as well as
how many DLCI's you want to assign to each Frame Relay Access Device (FRAD).
 
The DLCI uses a number of function calls to communicate with the FRAD, all
of which are stored in the FRAD's private data area. assoc/deassoc,
activate/deactivate and dlci_config. The DLCI supplies a receive function
to the FRAD to accept incoming packets.
 
With this initial offering, only 1 FRAD driver is available. With many thanks
to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E &
S508 are supported. This driver is currently set up for only FR, but as
Sangoma makes more firmware modules available, it can be updated to provide
them as well.
 
Configuration of the FRAD makes use of another net-tools program, 'fradcfg'.
This program makes use of a configuration file (which dlcicfg can also read)
to specify the types of boards to be configured as FRADs, as well as perform
any board specific configuration. The Sangoma module of fradcfg loads the
FR firmware into the card, sets the irq/port/memory information, and provides
an initial configuration.
 
Additional FRAD device drivers can be added as hardware is available.
 
At this time, the dlcicfg and fradcfg programs have not been incorporated into
the net-tools distribution. They can be found at ftp.invlogic.com, in
/pub/linux. Note that with OS/2 FTPD, you end up in /pub by default, so just
use 'cd linux'. v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for
pre-2.0.4 and later.
 
/vortex.txt
0,0 → 1,35
This document describes the usage and errata of the 3Com "Vortex" device
driver for Linux.
 
This driver supports the following hardware:
3c590, 3c592, 3c595, 3c597
 
When loaded as a module the following variables may be set:
name type description
debug int The debug message level, 0 (no messages) to 6 (wordy).
options int[] The media type override and card operation settings
(See list below.)
 
An example of loading the vortex module is
insmod 3c59x.o debug=1 options=0,,12
This sets the debug message level to minimal messages, sets the first card to
the 10baseT transceiver, the second to the EEPROM-set transceiver, and the
third card to operate in full-duplex mode using its 100baseTx transceiver.
(Note: card ordering is set by the PCI BIOS.)
 
Possible media type settings
0 10baseT
1 10Mbs AUI
2 undefined
3 10base2 (BNC)
4 100base-TX
5 100base-FX
6 MII (not yet available)
7 <Use default setting>
8 Full-duplex bit
8 10baseT full-duplex
12 100baseTx full-duplex
16 Bus-master enable bit (experimental use only!)
 
Details of the device driver implementation are at the top of the source file.
/alias.txt
0,0 → 1,196
NET_ALIAS device aliasing v0.5x
===============================
The main step taken in versions 0.40+ is the implementation of a
device aliasing mechanism that creates *actual* devices.
This development includes NET_ALIAS (generic aliasing) plus IP_ALIAS
(specific IP) support.
From version 0.50, dynamic configuration of max alias per device and
tx/rx stats for aliases added.
Also fixed inter-alias routing and arping problems.
 
Features
--------
o ACTUAL alias devices created & inserted in dev chain
o AF_ independent: net_alias_type objects. Generic aliasing engine.
o AF_INET optimized
o hashed alias address lookup
o net_alias_type objs registration/unreg., module-ables.
o /proc/net/aliases & /proc/net/alias_types entries
o /proc/sys/net/core/net_alias_max entry (affects hash table size
also)
o tx/rx stats
 
 
o IP alias implementation: static or runtime module.
 
Usage (IP aliasing)
-------------------
A very first step to test if you are running a net_alias-ed kernel
is to check /proc/net/aliases & /proc/net/alias_types entries:
# cat /proc/net/alias*
 
For IP aliasing you must have IP_ALIAS support included by
static linking ('y' to CONFIG_IP_ALIAS? question), or runtime module
insertion ('m'):
# insmod /usr/src/linux/modules/ip_alias.o (2.0.xx) or
# modprobe ip_alias.o
Also, dynamic loading is supported (kerneld).
You should have the following line in /etc/conf.modules (not needed
for newer modutils):
alias net_alias-2 ip_alias
 
Module options
--------------
From 0.5x ip_alias module supports a new option ("no_sel" symbol).
If no_sel is set (default is 0), alias association (device selection) with
foreign addresses will be disabled.
 
You will get:
- Faster operation by avoiding completely routing lookups.
Due to the "logical nature" of aliasing, netdevice SELection can only be
done based on info from network layer. When packet dst address isn't
one of my addresses, I query the routing table to see which netdevice
would be selected for packet _source_ address. This option avoids
doing so, and you must consider using it if you *only* have same-net
aliases (common usage).
 
You will loose:
- Inter-alias routing
- Proxyarp over aliases
 
To activate:
# insmod ip_alias.o no_sel=1
or
# modprobe ip_alias.o no_sel=1
or
add the following line to /etc/conf.modules:
options ip_alias no_sel=1
 
 
o Alias creation.
Alias creation is done by 'magic' iface naming: eg. to create a
200.1.1.1 alias for eth0 ...
# ifconfig eth0:0 200.1.1.1 etc,etc....
~~ -> request alias #0 creation (if it not exists) for eth0
and routing stuff also ...
# route add -host 200.1.1.1 dev eth0:0 (if same IP network as
main device)
# route add -net 200.1.1.0 dev eth0:0 (if completely new network wanted
for eth0:0)
 
o Alias deletion.
Also done by magic naming, eg:
 
# ifconfig eth0:0- 0 (maybe any address)
~~~ -> will delete alias (note '-' after dev name)
alias device is closed before deletion, so all network stuff that
points to it (routes, arp entries, ...) will be released.
o Alias (re-)configuring
Aliases *are* devices, so you configure and refer to them as usual (ifconfig,
route, etc).
o PROCfs entries
2 entries are added to help fetching alias runtime configuration:
a) /proc/net/alias_types
Will show you alias_types registered (ie. address families that
can be aliased).
eg. for IP aliasing with 1 alias configured:
 
# cat /proc/net/alias_types
type name n_attach
2 ip 1
b) /proc/net/aliases
Will show aliased devices info, eg (same as above):
 
# cat /proc/net/aliases
device family address
eth0:0 2 200.1.1.1
o PROCfs dynamic configuration (from v0.50)
You can now change the max aliases per device limit via
/proc/sys/net/core/net_alias_max entry (default=256)
# cat /proc/sys/net/core/net_alias_max
256
# echo 1000 > /proc/sys/net/core/net_alias_max
# cat /proc/sys/net/core/net_alias_max
1000
# _
With this funcionality you can disable net_alias creation from now on
# echo 0 > /proc/sys/net/core/net_alias_max
 
The new aliasing limit is considered (grabbed) when creating the
FIRST alias for the main device.
Eg:
# echo 10 > /proc/sys/net/core/net_alias_max
# ifconfig eth0:0 xx.xx.xx.xx (first alias creation for eth0,
eth0 will 'remember' max==10)
# echo 1000 > /proc/sys/net/core/net_alias_max
# ifconfig eth0:999 xx.xx.xx.xx
SIOCIFSADDR: No such device
Of course these semantics can be changed, please let me know.
Configuration changes get logged as usual (klogd -> /var/log/messages)
o Alias devices rx/tx stats
Fake rx/tx stats are accounted:
- TX
When the packet is ``switched'' from logical alias device to
physical device, tx counter gets incremented.
- RX
When an incoming packet's address equals alias network device's addr it
gets ``switched'' from physical to logical device, rx counter gets
incr.
Please NOTE that for ``same'' network alias devices you usually have
one net-route through physical device (eg. eth0), so output pkts
will NOT pass down via alias device (so, no tx++ will occur).
Also NOTE that currently ifconfig does not handle the ``:'' of alias devices
names, a little patch solves the problem:
--- ifconfig.c.dist Tue Apr 4 17:58:32 1995
+++ ifconfig.c Fri Oct 25 13:11:23 1996
@@ -243,7 +243,12 @@
bp++;
if(strncmp(bp,ifname,strlen(ifname))==0 && bp[strlen(ifname)]==':')
{
- bp=strchr(bp,':');
+ /*
+ * start bp at ifname end to prevent ':' ambiguity
+ * with alias devices (eg. eth0:0)
+ *
+ */
+ bp+=strlen(ifname);
bp++;
sscanf(bp,"%d %d %d %d %d %d %d %d %d %d %d",
&ife->stats.rx_packets,
Relationship with main device
-----------------------------
- On main device closing, all aliases will be closed and freed.
- Each new alias created is inserted in dev_chain just before next
main device (aliases get 'stacked' after main_dev), eg:
lo->eth0->eth0:0->eth0:2->eth1->0
If eth0 is unregistered, all it aliases will also be:
lo->eth1->0
 
Contact
-------
Please e-mail me:
Juan Jose Ciarlante <irriga@impsat1.com.ar> or <jjciarla@raiz.uncu.edu.ar>
Acknowledments
--------------
Special thanks to Claudia for all her love an patience.
Also thanks to Antonio Trevi~o <antonio@ecord.gov.ar> great human being
and un*x guru.
 
; local variables:
; mode: indented-text
; mode: auto-fill
; end:
/rcpci45
0,0 → 1,85
 
 
Application Information
 
The included application, called "rcc" (for RedCreek Control), is an
example of a user-space application (i.e., not running within kernel
space). It issues ioctl commands to communicate with the PCI driver.
It is intended for reference only. It can currently report any of
the following information:
 
- PCI driver information ("getinfo")
- card statistics ("getstats")
- card's ip address & netmask ("getipnmask")
- card's mac address ("getmac")
- current speed ("getspeed")
- firmware version string ("getfirmware")
- status of the link (up or down) ("getstatus")
 
This program needs to run as root, to avoid encountering permission
problems. An alternative is to change the permission and ownership
so that it runs as a setuid root process (for example, "chown
root.root rcc; chmod u+s rcc").
 
 
Quick PCI driver background
 
The adapter has its own IP and mac addresses which you have to
assign using the RedCreek manager (assuming the adapter is
running 3.X firmware). Your linux box will not know anything
about the adapter's IP address -- ie, the adapter will show up
as a regular nic. You will assign the linux box IP address using
the "ifconfig" command, as mentioned below.
 
To compile the driver, simply type "make".
This, of course, assumes that you have GNU compiler environment
already setup on a linux box. The .c and .h files were copied
to a dos filesystem (the floppy), so you may have to use "dos2unix" to
convert it back to a unix text file. Keep in mind that the driver
currently works with kernels 2.0.X only. Furthermore, it was only
tested with kernel 2.0.34. There is work being done on porting the
driver to the 2.1.X kernel, however, it's still incomplete.
 
When the compile is done, you'll send up with three object files
related to the driver: rcmtl.o, rcpci45.o, and rc.o; rcmtl.o
is the RedCreek API message layer; rcpci45.o is the upper level
Linux driver which contains the interface to the kernel. Finally,
since the driver is compiled as a loadable module, rcmtl.o and
rcpci45.o are linked together into a third file, rc.o, which is the
actual driver.
 
To load the driver:
 
"insmod rc"
 
If you are in console mode, you'll see a few messages send by the
driver. One of the messages will indicated how many adapters were
found; the messages are also stored in /var/log/messages, so they
can be viewed later. If you are running X, then you'll have to
view the messages by examining /var/log/messages.
 
The adapter will show up as a regular nic. Thus, if you have only
one nic (the pci card) in your box, you would at this point configure
it with the following commands:
 
mandatory:
"ifconfig eth0 <your linux box IP address (NOT the IP address of the
adapter!>"
"route add -net <your network address> eth0"
 
optional (if you want to be able to access other networks):
"route add default gw <your default gateway IP address> eth0"
 
Done. Type "ifconfig" to see "eth0" and the packet count, as well
as the IP address, net mask, etc.
 
To unload the driver, you first have to shutdown the interface:
 
"ifconfig eth0 down"
 
Then you unload the driver with "rmmod rc".
 
 
For technical support, please send email to Pete Popov at
ppopov@redcreek.com. Please have as complete of a description of
the problem as possible.
/net-modules.txt
0,0 → 1,293
Wed 2-Aug-95 <matti.aarnio@utu.fi>
 
Linux network driver modules
 
Do not mistake this to "README.modules" at the top-level
directory! That document tells about modules in general, while
this one tells only about network device driver modules.
 
This is a potpourri of INSMOD-time(*) configuration options
(if such exists) and their default values of various modules
on Linux network drivers collection.
 
Some modules have also hidden (= non-documented) tunable values.
Choice of not documenting them is based on general belief, that
the less user needs to know, the better. (There are things that
driver developer can use, others should not confuse themselves.)
 
In many cases it is highly preferred that insmoding is done
ONLY with defining an explicit address for the card, AND BY
NOT USING AUTO-PROBING!
 
Now most cards have some explicitly defined base address, they
are compiled with (to avoid auto-probing, among other things).
If that compiled value does not match your actual configuration,
do use "io=0xXXX" -parameter for the insmod, and give there
a value matching your environment.
 
If you are adventurous, you can ask the driver to autoprobe
by using "io=0" parameter, however it is potentially dangerous
thing to do in a live system. (If you don't know where the
card is located, you can try autoprobing, and after possible
crash recovery, insmod with proper IO-address..)
 
--------------------------
(*) "INSMOD-time" means when you load module with
/sbin/insmod you can feed it optional parameters.
See "man insmod".
--------------------------
 
 
8390 based Network Modules (Paul Gortmaker, Nov 12, 1995)
--------------------------
 
(Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200)
 
The 8390 series of network drivers now support multiple card systems without
reloading the same module multiple times (memory efficient!) This is done by
specifying multiple comma separated values, such as:
 
insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
 
The above would have the one module controlling four 3c503 cards, with card 2
and 4 using external transceivers. The "insmod" manual describes the usage
of comma separated value lists.
 
It is *STRONGLY RECOMMENDED* that you supply "io=" instead of autoprobing.
If an "io=" argument is not supplied, then the ISA drivers will complain
about autoprobing being not recommended, and begrudgingly autoprobe for
a *SINGLE CARD ONLY* -- if you want to use multiple cards you *have* to
supply an "io=0xNNN,0xQQQ,..." argument.
 
The ne module is an exception to the above. A NE2000 is essentially an
8390 chip, some bus glue and some RAM. Because of this, the ne probe is
more invasive than the rest, and so at boot we make sure the ne probe is
done last of all the 8390 cards (so that it won't trip over other 8390 based
cards) With modules we can't ensure that all other non-ne 8390 cards have
already been found. Because of this, the ne module REQUIRES an "io=0xNNN"
argument passed in via insmod. It will refuse to autoprobe.
 
It is also worth noting that auto-IRQ probably isn't as reliable during
the flurry of interrupt activity on a running machine. Cards such as the
ne2000 that can't get the IRQ setting from an EEPROM or configuration
register are probably best supplied with an "irq=M" argument as well.
 
 
----------------------------------------------------------------------
Card/Module List - Configurable Parameters and Default Values
----------------------------------------------------------------------
 
3c501.c:
io = 0x280 IO base address
irq = 5 IRQ
(Probes ports: 0x280, 0x300)
 
3c503.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ software selected by driver using autoIRQ)
xcvr = 0 (Use xcvr=1 to select external transceiver.)
(Probes ports: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, 0x2E0)
 
3c505.c:
io = 0x300
irq = 0
(Probes ports: 0x300, 0x280, 0x310)
 
3c507.c:
io = 0x300
irq = 0
(Probes ports: 0x300, 0x320, 0x340, 0x280)
 
3c509.c:
io = 0
irq = 0
( Module load-time probing Works reliably only on EISA, ISA ID-PROBE
IS NOT RELIABLE! Compile this driver statically into kernel for
now, if you need it auto-probing on an ISA-bus machine. )
 
8390.c:
(No public options, several other modules need this one)
 
ac3200.c:
io = 0 (Checks 0x1000 to 0x8fff in 0x1000 intervals)
irq = 0 (Read from config register)
(EISA probing..)
 
apricot.c:
io = 0x300 (Can't be altered!)
irq = 10
 
arcnet.c:
io = 0
irqnum = 0
shmem = 0
num = 0
DO SET THESE MANUALLY AT INSMOD!
(When probing, looks at the following possible addresses:
Suggested ones:
0x300, 0x2E0, 0x2F0, 0x2D0
Other ones:
0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
0x280, 0x290, 0x2A0, 0x2B0, 0x2C0,
0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370,
0x380, 0x390, 0x3A0, 0x3E0, 0x3F0 )
 
at1700.c:
io = 0x260
irq = 0
(Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
 
atp.c: *Not modularized*
(Probes ports: 0x378, 0x278, 0x3BC;
fixed IRQs: 5 and 7 )
 
de4x5.c:
io = 0x000b
irq = 10
is_not_dec = 0 -- For non-DEC card using DEC 21040/21041/21140 chip, set this to 1
(EISA, and PCI probing)
 
de600.c:
de600_debug = 0
(On port 0x378, irq 7 -- lpt1; compile time configurable)
 
de620.c:
bnc = 0, utp = 0 <-- Force media by setting either.
io = 0x378 (also compile-time configurable)
irq = 7
 
depca.c:
io = 0x200
irq = 7
(Probes ports: ISA: 0x300, 0x200;
EISA: 0x0c00 )
 
dummy.c:
No options
 
e2100.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ software selected by driver)
mem = 0 (Override default shared memory start of 0xd0000)
xcvr = 0 (Use xcvr=1 to select external transceiver.)
(Probes ports: 0x300, 0x280, 0x380, 0x220)
 
eepro.c:
io = 0x200
irq = 0
(Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340, 0x360)
 
eexpress.c:
io = 0x300
irq = 0 (IRQ value read from EEPROM)
(Probes ports: 0x300, 0x270, 0x320, 0x340)
 
eql.c:
(No parameters)
 
ewrk3.c:
io = 0x300
irq = 5
(With module no autoprobing!
On EISA-bus does EISA probing.
Static linkage probes ports on ISA bus:
0x100, 0x120, 0x140, 0x160, 0x180, 0x1A0, 0x1C0,
0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0,
0x300, 0x340, 0x360, 0x380, 0x3A0, 0x3C0)
 
hp-plus.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ read from configuration register)
(Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340)
 
hp.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ software selected by driver using autoIRQ)
(Probes ports: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240)
 
hp100.c:
hp100_port = 0 (IO-base address)
(Does EISA-probing, if on EISA-slot;
On ISA-bus probes all ports from 0x100 thru to 0x3E0
in increments of 0x020)
 
ibmtr.c:
io = 0xA20
(Probes ports: 0xA20, 0xA24 -- Ok, 0x220, 0x224, but IBM style..)
 
lance.c: *Not modularized*
(PCI, and ISA probing; "CONFIG_PCI" needed for PCI support)
(Probes ISA ports: 0x300, 0x320, 0x340, 0x360)
 
loopback.c: *Static kernel component*
 
ne.c:
io = 0 (Explicitly *requires* an "io=0xNNN" value)
irq = 0 (Tries to determine configured IRQ via autoIRQ)
(Probes ports: 0x300, 0x280, 0x320, 0x340, 0x360)
 
net_init.c: *Static kernel component*
 
ni52.c: *Not modularized*
(Probes ports: 0x300, 0x280, 0x360, 0x320, 0x340
mems: 0xD0000, 0xD2000, 0xC8000, 0xCA000,
0xD4000, 0xD6000, 0xD8000 )
 
ni65.c: *Not modularized* **16MB MEMORY BARRIER BUG**
(Probes ports: 0x300, 0x320, 0x340, 0x360)
 
pi2.c: *Not modularized* (well, NON-STANDARD modularization!)
Only one card supported at this time.
(Probes ports: 0x380, 0x300, 0x320, 0x340, 0x360, 0x3A0)
 
plip.c:
io = 0
irq = 0 (by default, uses IRQ 5 for port at 0x3bc, IRQ 7
for port at 0x378, and IRQ 2 for port at 0x278)
(Probes ports: 0x278, 0x378, 0x3bc)
 
ppp.c:
No options (ppp-2.2+ has some, this is based on non-dynamic
version from ppp-2.1.2d)
 
seeq8005.c: *Not modularized*
(Probes ports: 0x300, 0x320, 0x340, 0x360)
 
sk_g16.c: *Not modularized*
(Probes ports: 0x100, 0x180, 0x208, 0x220m 0x288, 0x320, 0x328, 0x390)
 
skeleton.c: *Skeleton*
 
slhc.c:
No configuration parameters
 
slip.c:
slip_maxdev = 256 (default value from SL_NRUNIT on slip.h)
 
 
smc-ultra.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ val. read from EEPROM)
(Probes ports: 0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380)
 
tulip.c: *Partial modularization*
(init-time memory allocation makes problems..)
 
tunnel.c:
No insmod parameters
 
wavelan.c:
io = 0x390 (Settable, but change not recommended)
irq = 0 (Not honoured, if changed..)
 
wd.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ val. read from EEPROM, ancient cards use autoIRQ)
mem = 0 (Force shared-memory on address 0xC8000, or whatever..)
mem_end = 0 (Force non-std. mem. size via supplying mem_end val.)
(eg. for 32k WD8003EBT, use mem=0xd0000 mem_end=0xd8000)
(Probes ports: 0x300, 0x280, 0x380, 0x240)
 
znet.c: *Not modularized*
(Only one device on Zenith Z-Note (notebook?) systems,
configuration information from (EE)PROM)
/tulip.txt
0,0 → 1,110
Tulip Ethernet Card Driver
 
The Tulip driver is developed by Donald Becker and changed by
Takashi Manabe. This driver is designed to work with PCI Ethernet
cards which use the DECchip DC21x4x family. This driver hopefully
works with all of 1.2.x and 1.3.x kernels, but I tested only
with 1.2.13, 1.3.39, 1.3.49, 1.3.52, 1.3.57 and later.
 
Hopefully, the de4x5.c driver will support all cards supported
by the tulip.c driver. However, the SMC's 9332dst card and some
cards do not work with the de4x5.c driver. So, if your card is
not a 9332dst, please try the de4x5.c driver first.
 
Success List
============
 
+-------------------------------------+-----------+-------------+
|vendor/card |chip |system |
+-------------------------------------+-----------+-------------+
|SMC | | |
| EtherPower 10 PCI(8432T/8432BT) |21040/21041|Pentium |
+-------------------------------------+-----------+-------------+
|SMC | | |
| EtherPower 10/100 PCI(9332DST) |21140 |Pentium/UDB |
+-------------------------------------+-----------+-------------+
|DEC | | |
| EtherWorks 100/10 PCI(DE500-XA) |21140 |Pentium |
+-------------------------------------+-----------+-------------+
|DEC | | |
| EtherWorks 10 PCI(DE450) |21041 |Pentium |
+-------------------------------------+-----------+-------------+
|DEC | | |
| QSILVER's |21040 |UDB |
+-------------------------------------+-----------+-------------+
|ZNYX | | |
| 312 etherarray |21040 |Pentium |
+-------------------------------------+-----------+-------------+
|Allied Telesis | | |
| LA100PCI-T |21140 |Pentium/UDB |
+-------------------------------------+-----------+-------------+
|Danpex ('Planet Japan' in Japan?) | | |
| EN-9400 |21040 |Pentium |
+-------------------------------------+-----------+-------------+
|Cogent | | |
| EM110 |21140 |Pentium |
+-------------------------------------+-----------+-------------+
 
Pentium: PCI machine with Pentium CPU
UDB: Universal Desktop Box(aka Multia) with Alpha 21066 CPU
 
Known bug(s)
============
This driver's media detection is very simple and sometimes
it causes serious problem. The driver automatically switches
media when it causes timeout. If you want to specify or to fix
a media;
 
- Modify TULIP_PORT in tulip.c, line 33.
- Uncomment the definition of TULIP_FIX_PORT in tulip.c, line 40.
 
or
 
- Use patched ifconfig command and specify 'link='. The patch
against ifconfig.c in net-tools-1.3.50-BETA6e is included in
this file.
 
Thanks
======
 
o becker@CESDIS.gsfc.nasa.gov (author of the tulip.c driver)
o davies@wanton.lkg.dec.com (author of the de4x5.c driver)
 
o siekas@mailhost.tcs.tulane.edu
 
o jheiss@calvin.caltech.edu (providing information about smc8432 card)
o goto@plathome.co.jp (lending me a DE450 card)
o ted@physics.ucsb.edu
o pmheuvel@xs4all.nl
o hjl@lucon.org (EN-9400)
o niles@axp745.gsfc.nasa.gov (ZNYX312)
o pkc@scs.carleton.ca (EM110)
o and testers...
 
-----------------------------------------------------------------------
*** ifconfig.c-dist Wed Jan 17 07:25:36 1996
--- ifconfig.c Tue Apr 9 15:24:25 1996
***************
*** 765,770 ****
--- 766,786 ----
continue;
}
ifr.ifr_map.irq = atoi(*spp);
+ if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
+ fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
+ goterr = 1;
+ }
+ spp++;
+ continue;
+ }
+
+ if (!strcmp(*spp, "link")) {
+ if (*++spp == NULL) usage();
+ if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) {
+ goterr = 1;
+ continue;
+ }
+ ifr.ifr_map.port = atoi(*spp);
if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) {
fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno));
goterr = 1;
/ppp.txt
0,0 → 1,25
The PPP support for this kernel requires the 2.2.0 version of the
pppd daemon. You will find the current version of the daemon on
sunsite.unc.edu in the /pub/Linux/system/Network/serial directory.
 
Sunsite has many mirror sites. Please feel free to obtain it from
a mirror site close to you.
 
If you attempt to use a version of pppd which is not compatible
then you will have some error condition. It usually is reflected
in that an ioctl operation will generate a fatal error.
 
Please do not use earlier versions of the 2.2 package. If you
obtained a copy from merit.edu or bellatrix then please get an
update from the sunsite site.
 
The CCP (Compression Control Protocol) which is supported by this
code is functional. You will need a compatible BSD compressor on
your peer site to use the code.
 
The BSD compression code will only build as a loadable module. There
was an earlier version which would build it into the kernel but that
functionality has been removed for various reasons.
 
--
Al Longyear longyear@netcom.com
/ncsa-telnet
0,0 → 1,16
NCSA telnet doesn't work with path MTU discovery enabled. This is due to a
bug in NCSA that also stops it working with other modern networking code
such as Solaris.
 
The following information is courtesy of
Marek <marekm@i17linuxb.ists.pwr.wroc.pl>
 
There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
remember the exact pathname, and this site is very slow from here).
It may or may not be faster for you to get it from
ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
(source is in v230704s.zip). I have tested it with 1.3.79 (with
path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
to work. I don't know if anyone is working on this code - this
version is over a year old. Too bad - it's faster and often more
stable than these windoze telnets, and runs on almost anything...
/3c505.txt
0,0 → 1,33
The 3Com Etherlink Plus (3c505) driver.
 
This driver now uses DMA. There is currently no support for PIO operation.
The default DMA channel is 6, and is set at compile time.
 
If no base address is given at boot time, the driver will autoprobe
ports 0x300, 0x280 and 0x310 (in that order). If no IRQ is given, the driver
will try to probe for it.
 
The driver can be used as a loadable module. See net-modules.txt for details
of the parameters it can take.
 
At the moment, the driver probably won't work with old (revision 2) hardware.
 
There is one compile-time setting in the CONFIG file:
ELP_DEBUG
The driver debug level. It's probably best to leave it at 0 most of the time.
If you are having trouble, setting it to 1 may give you more information.
Any higher setting is too verbose for most purposes.
 
To do:
Support for old boards
Make DMA configurable at run time
Improve probe/setup code
Test multicast and promiscuous operation
 
Authors:
The driver is mainly written by Craig Southeren, email
<craigs@ineluki.apana.org.au>.
Parts of the driver (adapting the driver to 1.1.4+ kernels,
IRQ/address detection, some changes) and this README by
Juha Laiho <jlaiho@ichaos.nullnet.fi>.
DMA mode, more fixes, etc, by Philip Blundell <pjb27@cam.ac.uk>
/ipx.txt
0,0 → 1,19
The IPX support in the Linux kernel has two modes of operation:
With and without the full internal IPX network. For all normal
operations, you do not need the full internal IPX network.
 
The full internal IPX network enables you to allocate sockets on
different virtual nodes of the internal network. This is done by
evaluating the field sipx_node of the socket address given to the bind
call. So applications should always initialize the node field to 0
when binding a socket on the primary network. In this case the socket
is assigned the default node that has been given to the kernel when
the internal network was created.
By enabling the full internal IPX network the cross-forwarding of
packets targeted at 'special' sockets to sockets listening on the
primary network is disabled. This might break existing applications,
especially RIP/SAP daemons. A RIP/SAP daemon that works well with
the full internal net can be found on ftp.gwdg.de:/pub/linux/misc/ncpfs.
 
If you want the full internal network, please uncomment the correspondig
#define in line 19 of include/net/ipx.h
/so_bindtodevice.txt
0,0 → 1,69
SO_BINDTODEVICE socket option for Linux 2.0.30+
by Elliot Poger (elliot@poger.com)
of Stanford's MosquitoNet project (http://mosquitonet.stanford.edu)
 
Using the SO_BINDTODEVICE socket option allows your user-level Berkeley
sockets code to explicitly select which network interface is used for
both input and output on a per-socket basis. I originally wrote it to
allow the Internet Software Consortium DHCP server
(http://www.fugue.com/dhcp/) to run on Linux machines with multiple
interfaces. It has been tested with UDP and TCP sockets.
 
Usage is as follows:
 
 
int skfd;
struct ifreq interface;
 
skfd = socket(AF_INET, SOCK_DGRAM, 0);
strncpy(interface.ifr_ifrn.ifrn_name, "eth1", IFNAMSIZ);
if (setsockopt(skfd, SOL_SOCKET, SO_BINDTODEVICE,
(char *)&interface, sizeof(interface)) < 0) {
perror("sendpacket: setting SO_BINDTODEVICE");
exit(1);
}
 
 
Once the BINDTODEVICE socket option has been set for a socket, as above,
any data sent over this socket is guaranteed to go out of the "eth1"
interface, and any data received through the socket is guaranteed to
have arrived on eth1. If you want to send and receive over multiple
interfaces, keeping them separate, you can open several sockets and bind
each one to a different interface with SO_BINDTODEVICE. (You _can_ call
BINDTODEVICE more than once for a socket to change the interface it's
bound to, but results may be unpredictable because of caching effects
in the kernel...)
 
Note that the routing table is still consulted when packets are transmitted.
Basically, routing proceeds as usual, except that any routes which go
through a network interface other than the one specified in the BINDTODEVICE
call are ignored. If you attempt to send a packet to a certain IP address
through an interface which provides no route to that IP address, you'll get
a "network unreachable" error. Here is an example of a routing table which
will allow you to send packets to any IP address through either eth0 or
eth1:
 
Destination Gateway Genmask Flags Metric Ref Use Iface
171.64.69.0 0.0.0.0 255.255.255.192 U 0 0 37 eth0
171.64.69.192 0.0.0.0 255.255.255.192 U 0 0 677 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 4 lo
0.0.0.0 171.64.69.1 0.0.0.0 UG 0 0 45 eth0
0.0.0.0 171.64.69.193 0.0.0.0 UG 1 0 5 eth1
 
Note that there are actually TWO default routes. The routing table is
searched from top to bottom, so every time you send out a packet, the first
(uppermost) matching route which the kernel routing function finds which
matches the destination IP address is used. In this case, packets sent to
the IP address 152.2.128.159 will normally be sent through eth0 and gateway
171.64.69.1; if the socket is bound to the eth1 device, the packets will be
sent through eth1 and gateway 171.64.69.193; if the socket is bound to some
other device, you will get a "network unreachable" error.
 
By the way, you can add multiple default routes and set the order of
preference as follows:
 
route add default gateway 171.64.69.1
route add default gateway 171.64.69.193 metric 1
 
Routes with a higher "metric" are put lower in the table and thus have a
lower preference.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.