|
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 <Philip.Blundell@pobox.com> Version: 1.32 See reader questions & answers on this topic! - Help others by sharing your knowledge 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://ftp.demon.co.uk/pub/archimedes/. Q. This FAQ is awful! Whose fault is it? A. Phil Blundell <Philip.Blundell@pobox.com> 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 <support@i-cubed.co.uk> 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 <Philip.Blundell@pobox.com> 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. User Contributions:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: Philip.Blundell@pobox.com (Phil Blundell)
Last Update March 27 2014 @ 02:11 PM
|
comp.sys.acorn.networking Frequently Asked Questions
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
comp.sys.acorn.networking Frequently Asked Questions
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]
Comment about this article, ask questions, or add new information about this topic: