ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/acorn/networking/faq

Text File | 1999-06-05 | 58.7 KB | 1,314 lines

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news-east1.sprintlink.net!news-peer1.sprintlink.net!news.sprintlink.net!nntp.primenet.com!dispose.news.demon.net!demon!news.demon.co.uk!demon!tazenda.demon.co.uk!not-for-mail
From: [e-mail] (Phil Blundell)
Newsgroups: comp.sys.acorn.networking,comp.sys.acorn.announce,comp.answers,news.answers
Subject: comp.sys.acorn.networking Frequently Asked Questions
Supersedes: <[e-mail]>
Followup-To: comp.sys.acorn.networking
Date: 4 Jun 1999 21:27:52 +0100
Organization: Impala Drive
Sender: [e-mail]
Approved: [e-mail]
Expires: 18 Jul 1999 20:27:51 GMT
Message-ID: <[e-mail]>
NNTP-Posting-Host: localhost
X-NNTP-Posting-Host: tazenda.demon.co.uk:158.152.220.239
X-Trace: news.demon.co.uk 928571464 nnrp-02:24176 NO-IDENT tazenda.demon.co.uk:158.152.220.239
X-Complaints-To: [e-mail]
X-Server-Date: 4 Jun 1999 20:27:52 GMT
Lines: 1293
Xref: senator-bedfellow.mit.edu comp.sys.acorn.networking:24473 comp.sys.acorn.announce:3843 comp.answers:36455 news.answers:159521

Archive-name: acorn/networking/faq
Posting-Frequency: monthly
Last-modified: 1998-04-19
URL: http://www.tazenda.demon.co.uk/phil/csan-faq
Maintainer: Phil Blundell <[e-mail]>
Version: 1.32

This file tries to collect together some of the accumulated wisdom to
do with networking of Acorn computers, in order to reduce the number
of times the same questions are asked in the comp.sys.acorn.networking
newsgroup.  Although the traffic in c.s.a.networking is not high, and
the signal-to-noise ratio is normally quite good, there are some
questions that tend to crop up repeatedly, and it gets a little
tedious for the regular readers to answer them every time.  Please
read this FAQ before posting.

Despite what the above paragraph might imply, not every question
answered in this document has necessarily been frequently asked.  Some
of the information has cropped up on the newsgroup only a few times,
or not at all, but still seemed interesting enough to be worthy of
inclusion.

This FAQ is divided into five parts.  If you're not interested in a
section, you can search for '**' to skip to the next one.

I am working on a pretty HTML version of the FAQ.  Until this is done,
it's only in plain text, and may not look too great in web browsers.
Also, updates may be sporadic (and the table of contents is missing)
since I have two copies to worry about right now.

This FAQ is posted monthly to comp.sys.acorn.networking and
comp.sys.acorn.announce, as well as news.answers and comp.answers.


** Section A: General stuff **

Q.  What's comp.sys.acorn.networking?

A.  This group is for discussion related to networking of Acorn machines.
This includes both connecting your own machine to the Internet and
running a local-area network of machines.


Q.  Are there any other newsgroups I ought to read?

A.  Yes.  You might like to check out comp.dcom.lans.ethernet,
comp.dcom.cabling and comp.protocols.tcp-ip for a start.  Many of the
people who know Ethernet bridges inside out, for example, don't read
comp.sys.acorn.networking.

If you're having trouble connecting to the Internet that may be
specific to your ISP, look to see if they have local support groups
first.

Of course, the other comp.sys.acorn.* newsgroups are the place to go
for Acorn discussion that isn't necessarily networking-related.

Several of these groups have their own FAQs, and you should check them
out as well.


Q.  Is there other good stuff available on the net?

A.  Yes.  Many vendors have their own web sites; see below.

There is a pile of LAN information, including the FAQ for
comp.dcom.lans.ethernet, at <http://web.syr.edu/~jmwobus/lans/>.

Acorn's ftp site has a pile of stuff, including online versions of
their Application Notes (nos 228, 231, 261, 264, 283 & 296 may be of
particular interest) and circuit diagrams for some of their hardware,
including Econet interfaces.  This can all be found at
<ftp://ftp.acorn.co.uk/pub/documents>.

Education people might like to look at
<http://sunsite.unc.edu/cisco/noc/> as well.

Kevin F. Quinn used to maintain a seperate FAQ containing information
on using Acorn machines for Internet access.  This document is quite
old now and has not been maintained for some time.  However, it may
still contain useful information.  You can get it from
ftp.demon.co.uk:/pub/archimedes/FAQ-Using-Acorns-For-Internet-Access.txt.


Q.  This FAQ is awful!  Whose fault is it?

A.  Phil Blundell <[e-mail]> put the FAQ together,
and he would appreciate comments and suggestions for improvement.
Many of the answers were provided by the amassed intelligence of
comp.sys.acorn.networking posters, of whom there are too many to list
them all individually.  Andrew Gordon provided a lot of the
information in, and checked the technical accuracy of, the Econet
section.  George Hawes, Dom Latter and others at i-cubed ltd provided
lots of useful information about Ethernet and AUN.


Q.  I'm an educational user.  What I really need to make my life of
drudgery more bearable is some sort of guide to Ethernet.

A.  You're in luck!  i-cubed limited have a document for just such an
eventuality.  You can find it on the Web (start from
<http://www.i-cubed.co.uk/> and follow the links through "Support").
Alternatively, if you need a paper copy, send email to
<[e-mail]> and ask nicely.


Q.  Can I ask people here to help me set up a network?

A.  By all means.  But remember to take advice you get with a pinch of
salt.  Networking can be a complex subject, and you ought to make sure
that the person who advises you knows what they're talking about
(which, sadly, isn't true of all Usenet posters) before you take their
advice too seriously (and particularly before you spend any money).


Q.  Who makes or sells Acorn networking equipment?

A.  Here is a partial list of suppliers with brief contact details.
Don't construe the inclusion of a company here as a recommendation.
If your company has been left out and feels hurt, send me email.

    i-cubed Ltd.  <http://www.i-cubed.co.uk>
    Xemplar Education.  <http://www.xemplar.co.uk>
    Atomwide Ltd.  <http://www.atomwide.co.uk>
    ANT Ltd. <http://www.ant.co.uk>


Q.  What's an `intranet'?

A.  Whatever you want it to be.  This question gets asked on the
newsgroup an awful lot, and usually provokes uninteresting rants from
a nunber of quarters.  If you post this question again, expect a
hostile response.

For those who really want an answer, there are some who believe an
`intranet' is any network on which TCP/IP protocols are used and that
is not part of the global Internet.  However, there is an alternative
school of thought that holds that an `intranet' must span many
continents, consist of many thousands of machines, and be owned by at
least five major world powers, and that anything less is merely a LAN
with aspirations.  And thirdly there are those who feel the word is a
vile piece of marketing-speak and that anybody accused of uttering it
should be shot on sight.


** Section B: TCP/IP and Ethernet **

Q.  What's IEEE 802.3?

A.  It's the standard document that defines Ethernet.  If you want the
last word on what is and is not allowed by the specification then this
is the place to look.  You can buy a copy from your local IEEE agent -
in the UK this is BSI.  It's quite expensive, but worth it if you do a
lot of work with Ethernet.


Q.  I want to run TCP/IP on my machine.  What do I need?

A.  Before anything else, you need a "protocol stack".  There are two
options here, Acorn's own Internet suite and Tom Hughes' FreeNet.
These days there probably isn't very much to choose between the two;
FreeNet has more features, but more people seem to use the Acorn
version.

Some useful URLs are:

    <ftp://ftp.acorn.co.uk/pub/riscos/networking>.  (Acorn TCP/IP)
    <http://www.compton.demon.co.uk/>        (FreeNet)

Once you've got the stack, you need a hardware driver for whatever
interface you want to use.  This might be an Ethernet card, or it
might be a serial line (with or without a modem) or it might be
something even more strange.  If you're lucky, your card will have one
in ROM (look for a module with a name like "Ether1" for an Ethernet
card).  If not, you may be able to find one on the net, or you may
have to talk to your vendor.  Then you should read the rest of the
questions in this section.


Q.  What's DCI?

A.  DCI is the Driver Control Interface, a way for protocol modules
(eg the Internet TCP/IP suite) to talk to the drivers for your
hardware (eg an Ethernet card).  DCI-2 was the first widely-released
version, and DCI-3 is to all intents and purposes the same.  DCI-4 is
a more recently developed replacement, which provides better
performance and increased functionality.  DCI-2 and DCI-4 are not at
all compatible; you must make sure that your protocol stack and your
hardware drivers are trying to use the same version of DCI.

Both FreeNet (from version 2) and Acorn Internet (from version 3) use
DCI-4.  DCI-2 is essentially obsolete now.

If you use !BootNet or !Gateway, you need to make sure you are using
the correct version to match the rest of your system - both DCI-2 and
DCI-4 versions exist.


Q.  Would it be possible to write a converter to make DCI-2 drivers
work with DCI-4 (or vice versa)?

A.  In theory yes.  However, this would only be a useful thing to do
if you're stuck with old hardware and no new driver.  As far as I know
nobody has actually written such a beast, but post to the newsgroup if
you're desperate and maybe someone will help you out.  Probably a
better plan, though, would be to find someone to write a new driver
for your card.


Q.  I want to write a network device driver.  Where can I get
information on DCI-4?

A.  Theoretically, this is freely available from Acorn.  In practice,
as with much of Acorn's technical documentation, it can be something
of a challenge to get hold of it.  There are two documents you need,
the DCI4 specification itself and the MbufManager programming
details.

To make matters worse, the "official" electronic version of the DCI-4
specification at Acorn now seems to be an Impression document, and the
person who imported it didn't take enough care to stop Impression
chewing up the C structure definitions (it has a habit of eating
anything starting with a '{' character, unless very carefully
restrained).  Intact versions of the document do exist, but it may
be even more difficult to get hold of one.  Acorn were apparently able
to ship the mangled specification for two years without anybody
complaining.


Q.  My Ethernet card has a driver in ROM (or I'm soft-loading one),
but Internet doesn't recognise it!

A.  You may be trying to mix DCI-2 and DCI-4.  Talk to your vendor to
see if you can get a ROM upgrade or soft-loadable replacement driver.
There are some updated driver modules included with the Internet
distribution on Acorn's ftp site.  The "EtherR" card by Risc
Developments needs a new ROM (costing ú10) - no soft-loading drivers
are available.

As far as I'm aware, DCI-4 drivers exist for most Ethernet cards that
have been made for Acorn machines.  The Atomwide/ANT "Pocket Ethernet"
adapter and all Digital Services cards are DCI-2 only.  If you're
using an A4, it looks like you're stuck with DCI-2 for the time being.
The Ether1 driver is apparently only of beta quality, but I haven't
heard of any problems with it other than its apparently incompatibility
with Internet 5.xx.


Q.  Do all the machines on my network have to use the same stack?

A.  No.  The protocols that your hosts talk on the wire is, at least
in theory, completely independent of the network stack, DCI and driver
versions that you're using.  If you're installing new machines, it's
probably a good idea to use the same stack on them all as far as
possible to make maintenance easier, but there's no pressing need from
a technical point of view.

Some people have reported problems when DCI-2 and DCI-4 stacks are
mixed on the same network.  There doesn't seem to be any evidence to
back this up,


Q.  How do I use TCP/IP over my modem (or null-modem link)?

A.  You need a SLIP driver.  There is one included with FreeNet; it
will work equally well with Acorn Internet.


Q.  Can I run TCP/IP over Econet?

A.  Yes.  You need a module called "EconetA", which provides an "ec0"
interface.  A new DCI-4 version of this module has just been released
by Xemplar, and can be obtained from their FTP site.  Note that this
module uses a different protocol over the wire to older EconetA
modules and so the two will not interwork, though they can coexist on
a network without interfering.

You can get a free DCI-2 version, including source, from
<http://www.tazenda.demon.co.uk/phil/>.


Q.  Does that work for Nexus Virtual Econet as well?

A.  Yes.  NexusVE behaves just like real Econet as far as TCP/IP is
concerned - you need the same EconetA module.


Q.  Can I run TCP/IP on a BBC micro?

A.  Strangely enough, yes (after a fashion).  Phil Blundell has some
software to allow you to use Econet-equipped BBCs as telnet
terminals.  If you have a roomfull of old machines and would like to
use them to talk to your Unix hosts, send email to
<[e-mail]> and ask for a copy.


Q.  I have more than one interface in my machine.  Can it act as a
gateway, relaying packets from one to the other?

A.  Yes, but this is disabled by default.  To turn it on, investigate
the *InetGateway command (for DCI-4 versions of Acorn Internet) or the
"ip forwarding" variable in !FreeUser.Files.Config (for FreeNet).


Q.  What's AUN?  Isn't that the same as TCP/IP?

A.  AUN has two distinct meanings. Primarily it is Acorn's networking
strategy (Acorn Universal Networking), and in this sense it covers the
full range of Acorn networking products which will work across
Ethernet networks

A second usage of AUN is to refer to the protocols used to access a
Level 4 file server, and to run a number of other network programs,
across an Ethernet network. In effect, this involves implementing the
protocols written for the older Econet network hardware on an
Ethernet.

While the two uses of AUN is confusing, no other term exists for the
`Econet over Ethernet' protocols and so in practice we are stuck with
AUN. In this second sense, AUN is implemented on top of UDP/IP.  Each
machine on an AUN network is, by default, given a non-standard IP
address of the form 1.x.n.s, where n.s are the network and station
numbers respectively.  The station number is configured in CMOS RAM,
using the SetStation utility.

If there are no stations on the network running the !Gateway
application then the network number will be 128, and the second byte
of the IP address will be 0, giving a typical IP address of 1.0.128.32
(station 32).

If any stations are running !Gateway then the network number is
configured within !Gateway, and the second byte of the IP address is
determined by the network's position in !Gateway's list of networks (1
for the first entry, 2 for the second, etc). Typical IP addresses
would then be:

          1.1.128.32     Station 32 on network 128
          1.3.129.36     Station 36 on network 129

Network numbers under AUN must be greater than 128; those between 1
and 127 are reserved for 'real' Econet.

Yes, it's a bit of a shame that Acorn chose to use 1.0.0.0 as the AUN
network number, but IP addresses like this should never go anywhere
near the real Internet anyway.


Q.  What about Access/Access+?

A.  These are Acorn's Peer to Peer networking products; Access is the
DCI-2 release, while Access+ is the DCI-4 version and has additional
features.  They allow computers to share files across an Ethernet
network. Any computer can export any directory, including $, on any
filing system, across the Ethernet network. The exported directory and
its sub-directories will then be available to all other computers
which have Access/Access+ software. Access+ also provides printer
sharing, although a computer with a shared printer must have a local
copy of !Scrap. This normally means it must have its own hard disc,
although it is possible for it to have a RAM disc set up with a copy
of !Scrap.

Access(+) is implemented using UDP/IP as its lower-level protocols; by
default it uses its own non-standard IP addressing scheme, where:

      First byte:  Always 1
      Second byte: Related to the make of the network card;
                     104 (&68) for i-cubed cards
      Third and fourth bytes: Last two bytes of the network card's MAC address.

The netmask used is 255.0.0.0.

It is possible to use Access(+) with AUN/Ethernet networking
(described above), in which case Access(+) uses the IP address set up
by AUN. It is also possible to use Access(+) with 'standard' IP
addressing, in much the same way as described for AUN
networking. (Note that if you are using Access(+) without AUN
networking you run !Internet to set up the required IP address and
netmask but DO NOT need to run !Bootnet.)

When using Access+, the system variable inet$localaddr is set to the
IP address in use, but with the order of the bytes reversed.

The command *FWShow gives information about the set-up of the
Access(+) network, with stations ("Holders") being identified by their
IP addresses. In this output lines marked with a * refer to the local
station.


Q.  What's masquerading?

A.  Masquerading is a way to allow machines to access (a limited
subset of) Internet services without having to have real IP addresses
assigned to them.  You may want to do this both for technical reasons
(if you've only been assigned one IP address, say for a dial-up
account, but you have a whole roomfull of machines you want to be able
to use) or for administrative reasons (you don't want your machines to
be able to have unfettered access to the Internet due to security
concerns).

To use masquerading, you need one firewall machine.  This must be able
to talk to the real Internet (so it needs a proper IP address) and to
the client machines that hide behind it, and are typically on a
private Ethernet.  Masquerading works by having the firewall rewrite
the headers on datagrams that pass through it from the hidden clients
to the outside world, so they look like they came from the firewall
machine itself.  When reply datagrams come back, the firewall
remembers where the original connection comes from, rewrites the
headers again, and forwards them to the appropriate client station.

All this means that masquerading is only good for outgoing
connections.  You can't telnet _in_ to a masqueraded machine from the
outside world.  This also means that FTP sessions will usually fail
from masqueraded machines - you must select passive mode first.


Q.  Can I do masquerading on my RISC OS machine?

A.  Yes, if you use the FreeNet stack.  Acorn's Internet module has no
support for masquerading.


Q.  What's proxying, then?

A.  Proxying is the technique of having outgoing requests (eg for web
pages) passed to a 'proxy server', which performs the request on
behalf of the original client and then forwards the results.  This can
be useful both if the clients can't be given direct access to the
Internet, and because it allows the proxy server to perform caching
and reduce the external bandwidth needed.  FTP, HTTP and gopher are
easy to proxy, given suitable clients.  Telnet is virtually impossible
to proxy transparently.


Q.  Now I'm confused!  It sounds like proxying and masquerading are
pretty much the same.

A.  To some extent they do the same thing, yes.  The difference is a
bit like that between routing and bridging.  Masquerading works at a
low level in the network stack; the datagrams are simply rewritten as
they pass through the gateway.  Proxying requires that you talk to a
server, which then talks to the outside world on your behalf.


Q.  What Ethernet cards are available?

A.  Several have been produced, though I'm not sure which are still
available these days.  A partial list is:

  Ether1: an Acorn card based on the Intel 82586.  Also known as the
    AKA25.  Has 10base2 and AUI (somewhat spuriously labelled
    "10base5") connectors.  This card has no real on-board ROM,
    so it's no use for diskless operation.

  Ether2: another Acorn card.  This uses an National Semiconductors
    8390 chipset.  Full details of the Ether1 and Ether2 cards can
    be found in the A500/R200 technical reference manual.

  Ether3: an Atomwide card based on a SEEQ chipset, available in both
    10baseT and 10base2 versions.  Acorn-badged versions of this
    were marked AEH54.

  EtherB: an ANT card, available in both 10baseT and 10base2 versions.

  EtherH: i-cubed's Ethernet card.  Equipped with both 10base2 and
    10baseT connectors, and available in flavours for standard
    Archimedes podules, A3000 mini-podule slots and RiscPC NIC
    slots.  Acorn-badged versions are marked AEH62 for the AUN
    version, and AEH78 for the Access+ version; they use a PROM
    for the firmware rather than the flash ROM found on i-cubed's
    own cards.

  EtherO: Oak's Ethernet card; 10base2 only, uses a Fujitsu chipset.

  EtherP: the "Pocket Ethernet" adaptor by Atomwide.  It has a BNC
    connector and plugs into the parallel port, deriving its power
    from the mouse socket.

  EtherR: Risc Developments / Beebug cards.  Available with 10base2,
    10baseT and AUI connectors, for all models of machines.

  EtherM: a RiscPC 'ethernet' socket card (ie not a full width podule,
    but designed for RiscPC only) by ANT.  Otherwise known as a
    'Myson' card, equipped with 10baseT(RJ45) and 10base2 connectors.
     Driver supposedly has problems with Internet 5, but in reality
    appears to work fairly well (EtherM 0.39, 10-Apr-1997).

A variety of other cards exist.  If you have a card that is not listed
here, or more information about one that is, please send email to the
FAQ maintainer.


Q.  I want to change to 10baseT cabling, but I have a huge investment
in old cards with no RJ45 connectors.  Help!

A.  If your old cards have AUI connectors (look for a 15-pin D type
socket, which may be labelled "AUI", "10base5", "Transceiver" or
something even weirder) then you can plug in an external transceiver.
These cost around 20ukp, and will let you use a 10baseT network
connection.  If the only connector on your card is the BNC for
10base2, then I'm afraid you're out of luck.  Media converters do
exist, but you're probably better off either keeping enough 10base2
segments to handle the old cards or replacing them with new ones.

You may find that installing a number of cheap hubs is the way
forward; this will allow you to use small 10base2 segments for your
old machines and connect them to a twisted-pair infrastructure.  Be
careful that you don't exceed the Ethernet limitations on repeater
count, however.


Q.  I fitted an Ether1 to my machine, but *Podules doesn't show it!

A.  The Ether1 has no ROM.  This means that *Podules has no way to
identify the card, and it will show up as a blank line (note that a
slot that is actually empty will show 'No installed podule').  Another
effect of this is that the Ether1 driver must always be softloaded,
unlike other cards which usually have the driver in firmware.


Q.  I'm trying to use my Ether1 card with Internet 5.xx, but I've come
to a sticky end.  Everything seems to be set up correctly but it just
doesn't work.

A.  There is a mysterious problem with Ether1 cards and newer versions
of the Internet module, which seems to result in no received frames
ever reaching the protocol stack.  As far as I know the only fix is to
go back to an older (4.xx) version of the Internet module.  The Ether1
driver has been unsupported for some time so it seems unlikely that a
fix will be forthcoming.


Q.  I want to use AUN networking but need to use IP addresses which fit
in with the non-Acorn computers on my site.

A.  This is quite straightforward in principle. If you are using the
Acorn Internet stack then you run the !Internet application; this
allows complete freedom of choice of IP address and netmask (but
conversely requires you to understand IP addressing and netmasking).

Having set the required IP address in this way, you run the !Bootnet
application. This replaces the Net module with the NetI module, which
is aware of 'full' IP addressing. The !Bootnet application has to be
configured to map the true IP addresses you are using onto the Acorn
net.station addressing convention.

The problem here is that stations which have run !Internet/!Bootnet
can not communicate with stations which are in the default
configuration.  Consequently running !Internet/!Bootnet from a network
server is quite difficult, and means that you will no longer be able
to communicate with that server once the applications have been run.
There are no such problems running !Internet/!Bootnet from a local
disc.


Q.  Aren't there any 100Mbps Fast Ethernet cards?

A.  No.  The expansion bus in current Acorn machines is too slow to
keep up with a 100Mbps card.  This doesn't mean that Fast Ethernet
cards would be useless, as you'd still have 100Mbps of bandwidth to
share between your clients, even if no single station could use it
all, but it does reduce the attractiveness a bit.  So far, no company
has seemed willing to invest the development effort to build a 100Mbps
card.


Q.  Why are Acorn network cards so expensive?  I can buy one for my PC
for ú20.

A.  That's true.  Cheap ISA network cards are made in vast quantities,
so they gain advantage from economies of scale, and require fairly
little development effort on the part of the vendor (they use a
standardised chipset optimised for the ISA bus, so no drivers need to
be written and very little board design is needed).  Acorn cards enjoy
none of these advantages, and the result is that the cost is higher.
The same is true for some ISA cards as well - the 3Com Etherlink III
(3C509), for example, uses custom components and needs its own
drivers, and costs about the same as a card for an Acorn system.


Q.  I want to connect two computers together with 10baseT.  Do I need a hub?

A.  No.  You can connect two (but no more) machines "back to back",
with a special cross-cover cable.  Consult the comp.dcom.lans.ethernet
FAQ for details of the wiring.


Q.  I'm trying to use 10baseT networking with a "combo" card but it doesn't
seem to work.  What could be wrong?

A.  Some combo cards, notably the i-cubed Etherlan 600 series, will
only switch to 10baseT mode if they detect a valid signal at the RJ45
connector.  This "link good" signal is generated by all hubs and
network cards, but you can run into trouble if you are trying to
connect two auto-sensing cards "back to back" as mentioned above -
neither card will switch to 10baseT mode until it sees a "link good"
signal from the other, and neither will generate "link good" signals
unless they are in 10baseT mode.  If you use a hub then this problem
will not occur.  The best solution is probably to replace one of the
cards with one that can be manually switched to 10baseT mode (or
indeed a 10baseT-only model) - if this is not possible then you can
use a loopback plug to fool one of the cards at startup.


Q.  I'd like to connect two machines using their parallel ports.  Is there
a PLIP driver for RISC OS?

A.  A few years ago somebody was working on one, but it seems to have sunk
without trace.  If anybody knows different, please say so.


** Section : Disk sharing, etc **

Q.  I want to use disks and printers that are connected to Unix
machines.  Can I do it?

A.  Yes, though not for free.  You need an NFS client.  The full Acorn
TCP/IP suite (which is a commercial product, unlike the stack itself
which is freeware) includes an NFS client, and ANT's OmniClient
software also includes NFS support.

Once you've obtained the necessary client software, you need to make
sure that your Unix machines are running the right servers.  You may
need to run "pcnfsd" or something similar in addition to your standard
NFS daemons to allow access from RISC OS machines.

The best way to share printers is currently with NFS.  If you don't
have NFS, and don't want to fork out for it just to print
occasionally, there is an lpr client for RISC OS available.  This only
works from the command line, and doesn't integrate with !Printers.
Get it at <ftp://ftp.demon.co.uk/pub/archimedes/utils/lpr010.zip>.


Q.  Okay, so the Unix people are happy.  But I use Windows for
Workgroups and/or Windows 95 and/or Windows NT.  Can I do the same
thing?

A.  Yes.

Microsoft systems use a protocol called SMB to share files and
printers.  This is carried on top of a system known as NetBIOS, which
in turn sits on top of _another_ protocol, which is either TCP/IP or
NetBEUI, the latter being a proprietary Microsoft protocol.

Two SMB clients are currently available for RISC OS, Omniclient and
RMLogon.


Q.  Hey!  I've got an SMB server for my Unix machine and I'm using it
to share files with my Windows machines.  But my RISC OS computers
can't talk to it!  What's the deal?

A.  Sadly, the SMB system isn't as simple as you might hope.  SMB sits
on top of a protocol called NetBIOS, which in turn sits on top of
another protocol.  This low-level transport protocol can either be
TCP/IP or NetBEUI, the latter being a proprietary Microsoft protocol.
Windows for Workgroups can only speak NetBEUI, though there is an
upgrade available to add TCP/IP support.  Windows 95 and NT can both
speak NetBEUI and TCP/IP equally well.

So far, so good.  Unfortunately, because NetBEUI is proprietary, it
_isn't_ supported by the servers you can run on Unix machines.
Normally this isn't a problem, because Windows will use TCP/IP to talk
to the Unix hosts.  However, Omniclient I has the opposite problem (it
can _only_ speak NetBEUI) and so it can't communicate with a Unix host
even though they're both running the same sharing system.

Omniclient II supports TCP/IP and so upgrading should solve your
problem.  Otherwise, you have to either use NFS to talk to Unix
machines, or find an NT machine to re-export the disks from the Unix
server.  Windows 95 won't do here, because irritatingly it seems not
to let you re-export a remote filesystem or printer.


Q.  What about Novell?  My PCs and Macs are happily talking to my
server - can my RiscPC do the same?

A.  Not directly.  To produce a Novell client for RISC OS the
protocols would have to be licensed from Novell (at great expense and
under non-disclosure) and nobody has seemed keen to do this.  If you
have an NT machine on hand, though, it should be able to talk to the
Novell server and re-export the filesystems with SMB.  You may be able
to pull the same trick with a Linux machine and ncpfs as well, though
this may not be so reliable.


Q.  Or AppleTalk?  Surely there must be _some_ hope for the Mac?

A.  Again, RISC OS machines can't talk directly to Macs, and there's
no immediate prospect of them being able to (though apparently
AppleTalk support is planned for a future release of Omniclient).
However, again, there is a partial solution available.  If you have a
FreeBSD or Linux server, installing the `netatalk' package will allow
it to talk to the Macs and access AppleTalk drives and printers; it
can then re-export them to the RISC OS world using NFS.


Q.  I'm running Acorn Access.  Is there any way I can share files over
a serial link?  I have SLIP set up, and I can ping one machine from
the other with no problems, but I can't see its disks.

A.  Not easily.  The problem is that the Freeway module refuses to use
any interface that it thinks isn't "broadcast capable" - and a
point-to-point link, such as a SLIP interface, doesn't fall into this
category.

People have talked of modifying Freeway to remove this restriction,
but as far as I know nobody has actually done so yet.  Aside from the
legal issues and the fact that recent versions of Freeway can't be
soft-loaded, there is an additional complication in that SLIP doesn't
have any way to distinguish different types of traffic passing over
it, and so you may come to grief if you try to run TCP/IP and Access
simultaneously on the same line.  PPP doesn't suffer from this
limitation.


Q.  I see Acorn are shipping Freeway in ROM with newer RISC OS
revisions.  Does that mean it's freely distributable now?

A.  No.  As with any other part of RISC OS, it's still commercial
software and you're still not allowed to copy it.  This means that,
for example, you aren't allowed to take the module from a new machine
and soft-load it (or blow it into an expansion card ROM) on old
machines.


** Section D: Econet **

Q.  We had a thunderstorm last night, and now my Econet doesn't work.

A.  One or more of your machines has probably had its interface
toasted by surges induced on the cable by lightning strikes.  Finding
out which ones is just a matter of trial and error - go round
unplugging stations until things start working again.  Don't forget
that it's not only client machines that can be damaged - your clock
and fileserver may have been taken out as well.

Once you've identified the afflicted stations, repairing them is
usually quite easy.  Econet interfaces use two line receiver chips and
one line driver.  Most machines use LM319 dual comparators as the line
receivers (except bridges, which use 26LS34s).  These are reputedly
fairly robust, and are protected by resistors from the full impact of
surges, so are less likely to fail than the line drivers.  The drivers
vary from machine to machine - BBCs and most SJ equipment use 75159s,
whereas Master, Archimedes machines and bridges use 26LS30s.

Unfortunately, these chips are often not socketed, so you may need to
do some soldering.  It's well worth taking the extra moment it takes
to fit a socket when you change one, as they can die quite frequently.

It's also worth changing, or at least testing, all three chips if you
suspect that one may be faulty.  One of the LM319s recovers the
incoming clock and data signals, and is needed for the interface to
work at all; the other is used for collision detection.  Without this
second receiver the machine will appear to work, but will have an
adverse effect on the reliability of the network.  You can also get
various bizarre effects from chips that have been damaged but not
destroyed - partial failure of a 75159, for example, can lead to a
machine working fine when it's switched on, but jamming the network
when turned off.

New Econet modules use surface-mounted components that can be
difficult to replace by hand.  By cutting some tracks on the board you
can disable these and fit ordinary DIL versions in the spaces provided.

If you find this happens to you an awful lot, or if you have long runs
of exposed cable, you may want to invest in some surge suppressors
(basically just some hefty diodes between the signal lines and ground)
to try to eat the surges before they eat your machines.  Another idea
that was floating around at one time, but as far as I know never
implemented, was to add opto-isolators onto one side of a bridge to
provide more complete protection from electrical accidents.  However,
before worrying about suppressors and particularly if you get through
a lot of drivers for no apparent reason, you should check that all
your electrical outlets are properly grounded.  Particularly in
schools, this is often not the case.  Make sure that you unplug all
your computers before testing the sockets, as otherwise you can get
earthing effects through your network that fool your socket tester
into thinking all is well.


Q.  I have an bridge on my network.  Sometimes my Archimedes and
Master machines don't seem to be able to find out their network number
(and default to 0) - what could be wrong?

A.  Make sure that the network on the other side of the bridge isn't
getting disconnected.  Acorn bridges will go dead to the world if
there is a fault on either of the two networks they're bridging
between.

It's also possible your network is just unreliable.  When a machine
starts, it broadcasts a single "interrogate bridge" message, and
listens for the response.  If the broadcast is lost, there will be no
response.  See the next question for what the problem might be.


Q.  My Econet doesn't seem to be reliable.  What might be wrong?

A.  Most Econet transactions take place using a "four-way handshake",
and will be retried if something goes wrong.  This means that the
underlying network can become quite unreliable before operations start
to go obviously wrong.  The first symptom that all isn't well may be
that things take longer than they should, broadcasts go missing, or
you find that you have certain files that refuse to be sent over the
network even though others are fine.  If you inspect the traffic with
a packet monitor, you may well see lots of repeated frames, and very
possibly a high number of "Aborted" or "CRC error" messages.

If the problems seem to be local to one machine, suspect its network
hardware or (more likely) the drop cable connecting it to the network.
If they're more widespread, there are several possible causes.  One or
both of your terminators may be faulty or missing - if you're using SJ
plug-in terminators in ordinary socket boxes it's quite likely
somebody has unplugged one.  You may have a fault in the network
cabling - a broken drain wire can cause various insidious reliability
problems, mostly because it upsets the characteristics of the
terminators.  You may have exceptionally high levels of electrical
noise on the line (though Econet's differential transmission lines are
usually very good at coping with this - check with an oscilloscope).
Check to make sure that you don't have any excessively long drop-leads
or spurs on the network - 2 or 3 metres is about the longest you ought
to use.  Finally, it may simply be that you're running the network too
fast - try slowing the clock down and see if matters improve.


Q.  I'm getting cryptic error messages from my Econet software.  What
do they mean?

A.  The Acorn "standard" error messages aren't always particularly
self-explanatory.  They are:

 - No clock.  This means that your machine is not seeing the clock
signal on the Econet line.  Probably your machine is not plugged in,
or the clock box is broken, or you have a faulty cable or machine
somewhere.  If only one machine gives this error and others are fine,
either its drop cable or its Econet hardware is probably at fault.

In an emergency, you can try swapping the 75159 chips between a BBC
and a clock box.  The 75159 is actually a dual driver, and the two
machines use opposite sides of it, so this trick can sometimes get you
going again if one driver has been toasted.

 - Not listening.  This means that the destination machine completely
ignored all the packets you sent to it.  Most likely it is switched
off, or disconnected from the network.  You may also have a faulty
cable or bad termination.  The remote machine may be accessing its
floppy disk or doing something else that locks out the network for a
long time.  If you get this error when you try to perform an immediate
operation, it probably means that the remote machine has the
protection bits set.

 - Net error.  This means that the destination machine acknowledged
the first frame of the packet (the 'scout frame') but failed to
acknowledge the data frame.  If this happens with your own code, you
may be transmitting more data than the remote has buffer space to
handle.  Otherwise, it probably means that you have electrical noise,
bad cabling or a faulty terminator on the network.

 - Line jammed.  This means that your machine was unable to gain
access to the Econet wire for a long time, because it appeared to be
permanently busy.  Almost always this happens because of a faulty
cable or terminator.

 - No reply.  Your packet was received by the remote machine, but its
reply didn't make it back to your station.  This may happen if a
server is running abnormally slowly for some reason, or because of any
of the general reasons above (bad cabling etc).

 - Station not present.  This is really a special case of 'not
listening', and occurs for the same reasons.


Q.  I'm trying to read files from %TAPE (or ~TAPE) on my SJ server,
but I get "No reply" errors every time!

A.  When you access the %TAPE pseudo-directory, the tape drive is
being used as a very slow read-only disk (MDFS tape drives, unlike
most, can actually do this).  It can often take several minutes for
the tape to be wound to the right place to find your file, during
which time the client times out.

If the server is lightly loaded, you may be able to just repeat the
command a few times - eventually all the data will be cached in the
MDFS's memory, and it can be returned straight away without waiting
for the tape.  If the server is busy this may not work, as it will be
constantly throwing away your data to make room for files other users
have requested.  Alternatively, on Master series and RISC OS machines
you can increase the time for which your machine will wait for a
reply.  Under RISC OS, this is done with the SWI NetFS_SetFSTimeouts;
the following bit of BASIC increases the reply timeout to 10 minutes.

    SYS "NetFS_ReadFSTimeouts" TO txC%,txD%,mpC%,mpD%,rD%,bD%
    SYS "NetFS_SetFSTimeouts",txC%,txD%,mpC%,mpD%,60000,bD%


Q.  Are there any network monitors available for the Archimedes?

A.  Yes.  Acorn have one, called "NetMonitor", which behaves much the
same as *NETMON on the BBC did (it gives you a dump of the packets in
hex).  I'm not sure if this is currently available.

Phil Blundell also has one of his own which is a bit more like SJ's
Ecomon - it tries to decode the packets into a more human-friendly
form.  You can get it from <http://www.tazenda.demon.co.uk/phil/>.


Q.  Can I build my own clock?

A.  Yes.  An Econet clock is a fairly simple device - it just has to
generate a steady square-wave on the two clock lines.  There is an
old circuit diagram in the back of the Econet Advanced User Guide,
and a more modern one (for the Level 3 clock) in the Econet Design &
Installation Guide.

Be warned, though, that if you use self-powered terminators the clock
has to provide a common-mode voltage to drive them.  A very simple
clock may require you to use powered terminators.

If you have an old issue 3 BBC, you can arrange for it to generate a
clock signal (and/or provide termination) by fitting a few extra
components to the motherboard.  This may not be a good idea, though,
because the Econet interfaces on those machines are slightly marginal
even at the best of times.


Q.  How fast does Econet go?

A.  Not very.  The exact speed you can get depends on what machines
you have connected - Archimedes and SJ MDFSs are comparitively fast,
whereas BBCs and older SJ servers are slower - and on the length of
the cable, and quality (or presence, for that matter) of termination.

Some theoretical maximum figures are:

    Archimedes    500Kb/sec (that's kilo*bits*), up to 25m
    MDFS (v1.06+)    300Kb/sec, up to 120m
    BBC 'B'        200Kb/sec, up to 275m

You can trade off increased speed for reduced length, and vice versa,
but exceeding these limits is likely to make your network unreliable.


Q.  I was told I need terminators, but my network seems fine without.

A.  You may get away with this, or you may not - it depends what
machines you're using, and on other characteristics of your network.
An Econet should have exactly two terminators, one at each end, and
you will get better performance if you stick to this rule.

Econet terminators do two things - they bias the data lines when
they're not being driven, and they absorb reflections at the end of
the cable.  If your network is short enough and your clock speed is
low enough, you may be able to live with the reflections and so the
second property is unnecessary.  Also, newer machines
(Master/Archimedes series) stand a reasonable chance of working
without the data lines being correctly biassed; BBC series and SJ
servers are a lot more sensitive in this respect.

It's also possible you have terminators without realising it.
Old-style SJ socket boxes (the square white ones that soldered on to
the cable) had a space inside for you to plug in a hidden terminator.
SJ also made seperate "secure terminator boxes" to go with the newer
black IDC-style sockets, though these are rather easier to spot.
Finally, you may have an old BBC doing duty as a terminator (see "Can
I build my own clock?" above).


Q.  I added a terminator, and now my network doesn't work!  I thought
they were supposed to be good!

A.  Maybe it's faulty.  Also, terminators are only good in moderation.
An Econet is supposed to be (electrically) a single bus in a straight
line, with no branches.  Some people seem to think that they can add
as many spurs as they like, so long as they terminate the ends - this
isn't true, and the extra termination will probably make things worse.
If you _need_ a T-junction, you will have to use a bridge.  If you
added a SJ self-powering terminator (or Acorn 'Level 3' passive
terminator) and your network was on the edge before, it's possible
that the extra load on the clock lines has pulled it far enough out of
tolerance to stop altogether.  A terminator combined with a broken
drain wire (see the earlier "My Econet isn't reliable" section) is a
particular recipe for disaster.


Q.  I found this old cream-coloured server with a black front panel.
It says "SJ" on the front and weighs about a ton.  What is it?

A.  It's an HDFS, the original self-contained SJ fileserver.  It's
probably a collector's item now.  It had an internal hard drive,
giving 20MB of online storage, and there was an optional tape streamer
for backup, which used DC600 tapes.  The other main notable feature of
its design is that it has two independent CPUs.


Q.  I found another cream-coloured server with "SJ" on the front.
This one isn't quite so old, and it's much smaller.  There's a single
button on the front, labelled "Remove Discs", and connectors on the
back for two floppy drives.

A.  It's an FDFS, the little brother to the HDFS.  It, also, is
probably a collector's item.  You may also, conceivably, come across
FDFSs being used in applications other than file servers - it was
possible to load different software into the unit to make it act as a
serial gateway, for example.  It takes two standard dual floppy
drives, giving you a total of 3200k of online storage at any given
time with its own disk format.


Q.  I've found an old fileserver, but I don't know what station number
it is.  Help!

A.  The traditional station number for a fileserver is 254, so try
that first.  In any case, if the server has been sitting unused for a
long time its battery may have gone flat, and it should default to 254
when it comes back up.  If it seems to be stuck on some weird number
and you have another machine to hand, you can use *STATIONS or *FSLIST
to try to track it down.  Holding down the button when you switch on
may also reset it to 254.

If all else fails, you can change the station number of an SJ server
from Utility Mode.  If you turn the keyswitch straight from "off" to
"system" (on MDFS and HDFS machines), the server should start up in
utility mode.  On an FDFS, turn the server on and then push the button
while all the drives are empty.  You should now be able to connect a
terminal to the serial port, and talk directly to the fileserver's
firmware.


Q.  My SJ server keeps flashing its "printing" lights, and refuses to
respond to the network.  And I'm not even printing anything!

A.  The printer buffer is probably full of system messages.  This
might be because you've turned logging on, or it might be because the
server is unhappy for some reason (it may be getting disk errors, for
example).  The server will stop until the buffer drains.


Q.  When I type "*USERS" on my SJ server, I see this strange user at
the bottom called "SYSTEM" (and maybe his friend, "SPOOL").  What's
going on?

A.  These are special psuedo-users that the fileserver uses
internally.  Some versions of the fileserver software (as far as I
know, all FDFS and HDFS versions, and early MDFSs) would actually let
you log them out, which usually brought the fileserver to a sticky
end. often corrupting the disk in the process.


Q.  My MDFS tape drive is faulty!  Can I get a spare?

A.  Not easily.  The MDFS used a bizarre species of tape drive that
pretended to be a direct-access device.  It's almost certainly easier
to find some other way to back up your files.  Some people have had
luck connecting other devices in place of the tape; Design IT are
apparently the people to talk to about this.


Q.  I've lost the system password for my SJ server!  How can I get back
in?

A.  Use the original boot disk that came with the server.  If you don't
have it then you need to read the manual, which explains what to do in
these dire situations.  Please don't ask the group for help; people will
be reluctant to give it you, lest you turn out to be a malefactor trying to
break into somebody else's server.


Q.  Can I connect my PC to an Econet network?

A.  Not easily.  Once upon a time there was a card called the
"Ecolink" to do this.  However, few were made, they weren't always
completely reliable, and the drivers only work with MS-DOS 3.3.  An
Ecolink is probably not something you want to install, except for
historical interest value.

If all you want to do is be able to talk TCP/IP with machines on the
Econet, you can use an Archimedes equipped with Econet and some other
interface (Ethernet, serial line, ...) as a gateway.

There have been rumours of a PCI-bus Econet card but nothing concrete has
emerged yet.  Work is ongoing to add support to Linux for Econet hardware.


Q.  Okay, so can I connect my PC to an Ethernet network and run AUN?

A.  Again no (though see earlier sections for other ways to share
files between PCs and Acorn machines).  Phil Blundell has some
experimental patches for Linux to add support for AUN-over-UDP
protocols.


Q.  When I switch on my Archimedes, it complains that the "configured
station number is invalid".  What's up?

A.  All Acorn computers since the Master have had their Econet station
number stored in the first byte of CMOS RAM.  If the battery goes
flat, or you reset the CMOS RAM, it will get cleared to zero - this
isn't a legal station number.  Archimedes machines notice this and
default to being station number 1 instead.  If your station numbers
are getting reset when you do a delete power-on, you need a newer
version of SetStation.

You need a program to change the station number.  Location 0 is
protected, so the normal OSBYTE call to write CMOS RAM won't affect
it.  The Archimedes program is called "SetStation", and may be
available from Acorn's ftp site.

Note that station 1 is actually an illegal value for AUN, and it's a
good idea to avoid it in any case to reduce the risk of duplicate
station numbers if a machine has its CMOS RAM reset.


** Section E: Cabling **

Q.  I've heard that my 10base2 network has to be earthed!  It isn't -
is this important?

A.  The latest IEEE standard specifies that 10base2 networks, like
10base5, have to be earthed at a single point (usually one of the
terminators).  If you're installing new cabling you ought to take note
of this, but there's probably no immediate cause for alarm if you've
got an existing (and working) network that isn't earthed.


Q.  Can I install my own Econet or Ethernet cabling?

A.  Yes, if you feel competent to do so - it can often be a lot
cheaper than paying a contractor to do it, though obviously you have
no comeback if you make a mistake.  It's not particularly difficult,
though it can be time-consuming.  You should probably take a trip to
comp.dcom.cabling if you have questions about the precise ins and outs
of installation.


Q.  How do I attach Econet or 10baseT cable to the socket boxes?

A.  You need a special insulation-displacement ("tonking") tool.  You
can buy one from RS; their order code is 470-128.  The IDC connectors
are the same that are used in some telephone sockets, and so the same
tool will work - and indeed if you're only installing one or two
sockets you can probably make do with the plastic tool that usually
comes with telephone extension kits.  If you're installing a lot of
sockets, though, you probably want the proper metal version.


Q.  I want to make my own 10baseT drop leads.  Can I?

A.  Yes.  You need some category 5 UTP cable, some RJ45 plugs, and a
special crimp tool to fix one to the other.  The wiring is "straight
through", so pin 1 connects to pin 1 and so on.  Be warned though that
you can't just connect wires to pins at random - things have to be
arranged so that one pair is on pins 1/2, one is on 3/6, one is on 4/5
and the last is on 7/8.  It doesn't matter which pair is which.  Note
that some of the cables you can buy off the shelf are actually wired
incorrectly in this regard, and may cause you problems.

Making your own leads as a way to save money may be a false economy.
It's quite a fiddly and time-consuming business, and you can probably
expect a significant failure rate (the plugs are single-use, so if you
get one wrong you have to cut it off and try again).  On the other
hand, it can be worth keeping the supplies you need in case you do
ever need a drop-lead in a hurry, or you need one that's slightly
longer than your supplier can provide.

Note that the cable used for connecting socket boxes to patch panels
is solid-core, whereas the cable used for drop leads is stranded.
It's not a very good idea to use off-cuts of solid core to make up
drop leads; not only is the cable more brittle and prone to fail when
flexed, but you need a different design of RJ45 plug to make a
reliable connection with solid core cable.


Q.  I have a 10base2 network, and it doesn't work.  Is there any way
to trace the fault, other than checking each cable individually?

A.  If you can shut down the entire network (not difficult if it's
broken anyway) and you have a multimeter at your disposal, you can
check for gross faults fairly quickly.  Disconnect the cable at some
convenient point by removing a T-piece; you should be left holding two
BNC plugs, one connected to each half of your network segment.  For
each one, measure the resistance between the centre pin and the
outside body of the plug.  If all is well, you should get a reading of
50 ohms, give or take a few.  If the resistance is significantly lower
than this, you may well have a short circuit somewhere on the line -
maybe a bad connector, or maybe somebody stuck a pin through the
cable.  If it's significantly higher, you probably have an open
circuit at large - perhaps somebody undid one of the BNC twist-locks,
or perhaps a cable has broken internally (this happens more often than
you might think).  By repeating this procedure at strategically-chosen
points along the network, you should be able to narrow down the area
of the fault fairly quickly.  See also the next question for a
possible alternative approach.

If all else fails, throw the whole lot away and replace it with
10baseT cabling.  Then, next time a fault happens, you can just look
at the lights on the hub and know straight away which link is to
blame.


Q.  I have a long run of cable, and there's a break or short somewhere
in it.  Is there any way to pinpoint the fault?

A.  Yes.  The main reason that network cables need to be terminated is
to avoid reflections, and it is possible to turn this fact to your
advantage.  If there is a break or short-circuit in the cable, it will
no longer be terminated with its characteristic impedance, and
waveforms will "bounce off" the end.  By injecting a pulse into the
cable and timing how long it takes for the reflection to come back,
you can gauge the distance to the fault quite accurately - this is
handy if you have a long run of buried cable, for example, and don't
want to have to dig up the whole lot to fix it.

This procedure can't quite be done with normal household items, but it
doesn't require anything particularly exotic - if you're in a school,
your physics department should be able to furnish you with everything
you need.  Essentially, you need some source of regular sharp pulses,
and a fast oscilloscope to watch the action with.  You should find,
once you've adjusted the scope correctly, that you see the pulse
you're injecting onto the wire, and then a short time later a smaller
pulse which is the returning reflection.  The polarity of the
returning pulse will depend on whether the fault in question is an
open or short circuit.  The time between the original pulse and its
reflection is the time the waveform takes to make the round trip to
the fault and back, so the distance to the fault is given by half that
time multiplied by the velocity of the signal (which is a property of
the cable - usually around 70% of the speed of light).

You can buy devices known as time-domain reflectometers (TDRs) to do
this automatically.  These used to be very expensive, but are now
sufficiently affordable that one might be within your budget,
especially if it saves you from the prospect of paying to have
hundreds of metres of cable dug up and replaced.  Some Ethernet cards,
for example the Acorn Ether1, also have on-board TDRs - these are less
accurate than stand-alone units, but may still be able to give you a
useful clue as to where the fault lies.


Q.  Can I use my old Econet cables for Ethernet?

A.  Yes, for Base-T point-to-point links.  Econet cable is superior to
Cat-5, but it has only four wires and is more expensive: it has also
not yet been tested at 100 Mbits/sec.  You can tonk the ends straight
into the IDC connections on the backs of the RJ-45 outlets.  For
standard SJ cable connect

     (Clock -, DIN 5)  Blue   to 1  (white/orange)
     (Clock +, DIN 3)  Yellow to 2  (orange)
     (Data -,  DIN 4)  Red    to 3  (white/green)
     (Data +,  DIN 1)  Green  to 6  (green)

This cable will certainly work to well over 150 metres, but not if
there are a string of Econet outlets attached to it. If you are using
this on a large site, you will find that Base-T hubs are a lot more
resistant to lightning damage than Econet line drivers.

Such an installation is not in any way marginal; this cable conforms
to the IEEE 802.3 requirements for 10baseT links and so will be as
good as the more standard UTP cable.


** Section F: Internet Servers **

Q.  I've heard that Unix machines are better for running servers than
RISC OS.  Is that true?

A.  In general, yes.  The state of the art in server technology is
usually more advanced for Unix than for RISC OS.  If you have
requirements for mail handling, for example, beyond anything very
simple then you will probably have trouble under RISC OS.  The same
applies if you want to run your own news server, or provide ftp access
for multiple users with flexible access controls.


Q.  But isn't a Unix machine really expensive?  Aren't its commands
really arcane and difficult to use?

A.  Not necessarily.  There are now a number of free "Unix clones",
such as FreeBSD and Linux.  Given a copy of one of these, and
virtually any PC machine (for example, an old 386 or 486 that's been
retired from duty as a Windows machine), you can build your own Unix
server at pretty minimal cost.  Take a look at
<http://www.freebsd.org/> and <http://www.linux.org.uk>.

It's also not true that Unix is inherently difficult to use.  It can
be a bit daunting at first, but there are plenty of books available to
teach you the basics.  Given one of these, a machine to practice on,
and a bit of time and determination it's remarkably easy to pick up -
and once you start to learn the system, people tend to find that it's
far more intuitive and easy to use than DOS.


** The End **

Here endeth the comp.sys.acorn.networking FAQ.