So, what do you need to get Arcnet running?

• two adapter cards - here I'm assuming you have the most common type: ISA bus, coaxial cabling, STAR topology
• one cable - officially the 93-Ohm RG-62A/U, but for a short distance the 75-Ohm TV coax should be good enough
• two computers with matching slots - Arcnet cards don't use ISA DMA, thus they may work even with those modernish ISA-like things that lack DMA
• compatible software

Almost all Arcnet cards for ISA are based on COM90xx series chips (or compatible), therefore one driver fits all.
They even have the same factory settings:

• I/O 2E0..2EF (16 ports) - conflicts with COM4 at 2E8
• MEM D0000..D1FFF (8 KB) - be careful if you're using the UMB area for anything else
• MEM D2000..D3FFF (8 KB) - only if there's a BOOT ROM installed
• IRQ 2 (equals IRQ 9) - set IRQ 9 to "Legacy ISA" in BIOS where applicable

It's important to correctly set the NODE ID DIP-switches:

• can't be 00000000
• can't be 11111111
• must be unique for each of the stations

There's plenty of software with Arcnet support...

For a quick start, you can use Windows 9x - it comes with the necessary drivers, "Add New Hardware" can find the adapter, just be careful to select correct IO/MEM/IRQ if something gets misdetected.
And then it just works - you can eg. normally share the files.

You can also share files between Win9x and DOS with Microsoft Network Client 3.0.

Arcnet drivers shipped with Windows 9x are NDIS 2.0 (Real mode), and can be used with the three common protocols:
- IPX/SPX
- NetBEUI
- TCP/IP, using "Ethernet-encap"

It may be preferred to use ODI driver instead, which works with:
- IPX/SPX
- TCP/IP, using RFC1201

I'm attaching the ODI driver - load LSL.COM and SMCARCWS.COM from AUTOEXEC.BAT, and then add "Existing ODI Driver".
I'm also attaching an Arcnet BOOT ROM - but that's only because I want to have a backup in case the EPROM evaporates 🤣

Now, some benchmarks...

Server:
- Pentium III 800EB
- ISA 16-bit Arcnet card
- Windows 98 SE

Client:
- Celeron 266
- ISA 8-bit Arcnet card
- Windows 98 SE

SMB copy a file from the server's HDD to the client's NUL.
All results in KB/s.

NDIS + IPX/SPX: 132
NDIS + NetBEUI: 150
NDIS + TCP/IP: 116
ODI + IPX/SPX: 129
ODI + NetBEUI: doesn't work
ODI + TCP/IP: 192

In theory, Arcnet is 2.5 Mbps = 312 KB/s; actual measured performance isn't as close to the theoretical limit as with the Ethernet.
I guess it's due to shorter frames, and with NDIS+TCP/IP there's the additional overhead of "Ethernet-encap" - with both Arcnet header and Ethernet header transmitted, there's less room for payload.

Now, let's connect from Arcnet LAN to modern computers...

Arcnet adapters for modern buses - PCI, PCIe, USB - do exist, but they are niche and expensive.
So I decided to build an Arcnet<->Ethernet router, using a Pentium III machine with Linux.

There are three methods for transmitting IP traffic over Arcnet networks, incompatible with each other:

• RFC1201 - the final standard, probably the best
• RFC1051
• Ethernet-encap

Various software supports various methods:

• Linux 2.3.35 and below (Arcnet driver 3.02 and below): RFC1201, RFC1051, Ethernet-encap
• Linux 2.3.36 and above (Arcnet driver 3.91 BETA and above): RFC1201, RFC1051
• Microsoft Network Client 3.0 for MS-DOS: Ethernet-encap
• PD apps using ARCETHER, ARCPSF, SMCARCWS+ODIPKT: RFC1201
• PD apps using SMC_ARC+DIS_PKT: Ethernet-encap
• Windows 9x using own drivers: Ethernet-encap
• Windows 9x using ODI drivers: RFC1201

So, the best system for the router seems to be Linux 2.2 - I will try it sometime.

As of yet, I've only tested Red Hat 7.3 (based on kernel 2.4.18-3) - here's the procedure for this distro...

Install the package "kernel-source-2.4.18-3.i386.rpm", copy the source from /usr/src to your home directory, and then:

make menuconfig
- Load an Alternate Configuration File: /boot/config-2.4.18-3
- Network device support -> ARCnet devices -> set everything as module:

- Exit, save

make dep
make bzImage
make modules
su
make modules_install
make install

Reboot to the custom kernel, and then you can use the following script:

1insmod arcnet
2# insmod arc-rawmode
3# insmod rfc1051
4insmod rfc1201
5insmod com90xx
6ifconfig arc0 192.168.1.4 netmask 255.255.255.0
7echo "1" > /proc/sys/net/ipv4/ip_forward
8service dhcpd start

ifconfig should display something like:

1arc0      Link encap:ARCnet  HWaddr 01  
2          inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
3          UP BROADCAST RUNNING  MTU:1500  Metric:1
4          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
5          TX packets:0 errors:0 dropped:0 overruns:0 carrier:357
6          collisions:0 txqueuelen:30 
7          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
8          Interrupt:9 Base address:0x300 Memory:d0000-d07ff 

Note that I've disabled modules "arc-rawmode" and "rfc1051" - that's because they decrease the MTU to 508 and 507 bytes, which reduces performance.
Only enable them if really necessary!

Hint: to access a Samba server by name across a router, you can enter its IP to the DHCP server config, eg.:
option netbios-name-servers 192.168.169.170;

Excellent writeup but how do you plan to entice people to trying it with zero pics of the hardware?

maxtherabbit wrote on 2026-08-13, 13:29:

Excellent writeup but how do you plan to entice people to trying it with zero pics of the hardware?

Oh, there's plenty of pictures online - I'm sure everybody interested can easily find them.
I'm not trying to provide everything, only some practical info that I haven't seen online, and had to figure it out experimentally.

Networking was a bit of a Wild West until it all crystallised around Ethernet/Twisted Pair in the mid 90s. I believe the early editions of Networking for Dummies give a short description of Arcnet and others, but by 3rd edition I think, not a peep.

I maybe have a couple of Arcnet cards, but if I do I only saved them because they had special talents... they were also switchable to Ethernet Thin Coax. So that is the mode I am most likely to use them in if I need 8 bit NICs. I have a hub with a thin coax segment on. Another oddity from the "things aren't set in stone yet" era was some I think DECnet cards, which have a proprietary "long segment" mode, exceeding maximum segment length of standard Ethernet thin coax.

Be aware that if you seek to buy Arcnet cards, that there was also a twisted pair version, which needed a hub.

So is there practical reasons for wanting to mess with alternate network hardware? Well maybe if you're stuck with a proprietary bus machine that came with an arcnet adapter, or you find one cheap, and Ethernet ones are $$$, *cough*MCA*cough*.... buuuut we're getting to times where 8 bit compatible NIC are not necessarily easy to find, so having options might be good.

I think it is cool that people are experimenting with pre ethernet networking.

Years ago, I snagged a bunch of Token ring stuff to play around with but never got far with (MAU hub, ISA, MCA, Nubus, and even EISA cards plus I think I even had a TR printer interface for my HP 4SI).

Thank you for taking one for the team and trying Arcnet!

I also was always drawn to networking technologies like Arcnet, StarLAN, Token Ring, HomePNA, HomePlug/Powerline, Apple only PhoneNet/LocalTalk, ADSL/DSL/SDSL, Docsis, not to mention wireless ones like AlohaNet (daddy of wired Ethernet and later Wifi), WaveLAN (NCR/Lucent, precursor to 802.11b), HomeRF (Intel AnyPoint Wireless), Metricom Ricochet (https://www.joelonsoftware.com/2000/12/20/the … modem-a-review/) and even weird early mobile telephony like CT2 (Neal Stephenson In the Kingdom of Mao Bell https://www.wired.com/1994/02/mao-bell/ ) but trying it all it just too much. Thats why Im soo glad there are people out there like The Serial Port https://www.youtube.com/@theserialport, clabretro https://www.youtube.com/@clabretro and posts like yours 😀

Now that the router is running, let's do some benchmarks in this setup:

ModernServer -> Ethernet -> Router -> Arcnet -> CeleronClient

There are several Packet Drivers available for standard Arcnet cards:

• ARCNET.COM - from Crynwr, Class 8 (native Arcnet), "Note that a packet driver client must specifically support ARCNET. The only known client is Phil Karn's (KA9Q) networking package, NOS." - I'm not touching it now
• ARCETHER.COM - from Crynwr, Class 1 (Ethernet), uploads with MTU>504 fail, fails to load on my P3-800
• ARCPSF.COM - from https://web.archive.org/web/20060925233314/ht … penwarr/arcnet/ , Class 1, patched version of ARCETHER.COM, uploads with MTU>504 work, but still fails to load on my P3-800
• SMCARCWS.COM + ODIPKT.COM - Class 1
• TRXNET.COM + ODIPKT.COM - Class 1
• SMC_ARC.DOS + DIS_PKT.DOS - Class 1, uses Ethernet-encap = incompatible with my current router

I'm attaching them all...

All downloads in BINARY mode to NUL, in KB/s:

mTCP FTP, ARCETHER, defaults: 122
mTCP FTP, ARCETHER, MTU 1500: 149
mTCP FTP, ARCPSF, defaults: 122
mTCP FTP, ARCPSF, MTU 1500: 149
mTCP FTP, SMCARCWS, defaults: 142
mTCP FTP, SMCARCWS, MTU 1500: 179
mTCP FTP, TRXNET, defaults: 142
mTCP FTP, TRXNET, MTU 1500: 179

Win98SE FTP, SMCARCWS: 187
Win98SE SMB, SMCARCWS: 178

Yes, setting mTCP to "MTU 1500" can be a good idea even in non-pure-Ethernet scenarios!
Edit: but in this case, it's only good for downloads - and very bad for uploads.
Overall, leave MTU at the default of 576, or even decrease it to 504.

And it's yet another case where native Packet Drivers are slower than other drivers with shims.

FTP4DOS works as well:

Now things are getting hard - uploading:

CeleronClient -> Arcnet -> Router -> Ethernet -> ModernServer

All uploads in BINARY mode from HDD, in KB/s:

Win98SE FTP, SMCARCWS: 164
CUTCP FTP, SMCARCWS: 31
WatTCP FTP, SMCARCWS: 12

Well, sometimes sluggish, but always perfectly stable.

Getting the mTCP FTP client to properly upload, however, was a real pain - slow and/or unstable transfers, and often total hangs.
I suspected misconfigured MTU, so I carried out exhaustive measurements for all four compatible drivers:

ARCETHER completely fails with MTU>504, obviously because 504 octets is the maximum of client data per Arcnet frame.
The other drivers allow for more, but it gets unstable - at the default of 576 it's still tolerable, but really bad when approaching 1500.

NetDrive needs MTU>1200, so I'm afraid no way - I couldn't get it to work even with a read-only image, ie. download-only, even though large MTU doesn't hurt with FTP downloads.

For comparision, see the elegant behavior of Ethernet:

Yes, here it hits the HDD speed limit, hence the plateau.

BTW: CUTCP and WatTCP don't support DHCP, only BOOTP, so configure the DHCP server accordingly:
range dynamic-bootp 192.168.1.100 192.168.1.199;

So what do you think is happening? Is it a lack of buffer space in packet driver or shims? Is it the overhead of copying data around multiple times where a pure Ethernet packet driver only has to do it once? Did you experiment with the TCP buffer sizes?

A trace from one of the slower transfers might shed some light on what is happening.

The current version of NetDrive requires around 1100 bytes for the MTU. It could be made to work with an MTU around 576 if the code was told to never try to send more than 1 block per command. Is that something you think is needed?

mbbrutman wrote on 2026-08-18, 19:56:

Is it a lack of buffer space in packet driver or shims?

Unlikely.
For ODI I'm using "buffers 16 1600", which seems overkill - the only setup that really needed so many buffers was "fast NIC + slow CPU" (3C515 + 386), Arcnet + Celeron is the exact opposite!

Anyway, I've benchmarked SMCARCWS again, with "buffers 4 1600" - and can't see a difference:

Did you experiment with the TCP buffer sizes?

You mean FTP_TCP_BUFFER, right?
I didn't touch it - it's only for receiving data, isn't it?
I haven't seen any problems when receiving, only when sending.

A trace from one of the slower transfers might shed some light on what is happening.

Attaching a case that's consistently slow: SMCARCWS, MTU 1500, buffers 16 1600.

The current version of NetDrive requires around 1100 bytes for the MTU. It could be made to work with an MTU around 576 if the code was told to never try to send more than 1 block per command. Is that something you think is needed?

I would like to give it a try - at 1100 it's already very unstable, but at 576 it's still good enough.

There may be more problems with NetDrive, though.
With ARCPSF, it fails when connecting:

With ODI, it does connect, but then can't read files - same problem as with the Ethernet:

Perhaps it would be a good idea to investigate the incompatibility with ODI first?

One more thing:
I'm trying to ping mTCP (nc -listen 12345) with large packets, but it won't respond to pings > 256 Bytes - is this limit really necessary?
I was hoping to find what's the problem with such packets, whether they are lost, where they are lost, etc...

I'm pretty sure I know what's going wrong with FTP sending; it's not respecting the MTU you are setting. I'll fix that in the next release. If you are willing, I'll send you test code first.

Edit: on closer inspection the bug is not there. It is respecting MTU on sending.

NetDrive being able to connect doesn't really mean anything as it is a standard c program using UDP like most of the other mTCP programs. The device driver only cares about talking to an ethernet packet driver, so if you have something that emulates an ethernet packet driver it should be fine. EtherSLIP is a good example that shows it works.

mbbrutman wrote on Today, 13:51:

If you are willing, I'll send you test code first.

Sure, I want to try...

I just edited my previous post; the bug I thought might be there is actually not there.

Please send me a packet trace so we can figure out what is going on.

mbbrutman wrote on Today, 14:25:

Please send me a packet trace so we can figure out what is going on.

See the ZIP attached to this post - Re: Arcnet

The trace shows an MTU of 1500, so each outgoing packet gets 1460 bytes of payload. (20 bytes are reserved for the IP header, and another 20 bytes for the TCP header.)

The retry rate is pretty poor - 5% of packets are being lost and have to be resent. That's going to cause some noticeable gaps in the network traffic.

I suspect that the conversion layer is taking each outgoing packet and breaking them up into 3 or 4 packets depending on the actual MTU of your Arcnet. I don't know how that is supposed to work under the covers because to do that you either need to convert 1 large TCP packet into 3 smaller TCP packets, including rewriting the IP and TCP headers. Or you have to do something janky like send the first packet with a magic bit that says "First of 3 incoming packets, and then wait for two more non-standard packets to come in so that you can combine them into one packet for presentation to mTCP.

IP Fragments is supposed to take are of this problem, but I'm certain your shims are not doing that. IP Fragments are also expensive for the receiving side, as they have to provide enough buffer to reassemble things. (mTCP has some limited ability to handle IP fragments.)

Anyway, I'm not sure what's going on in those packet driver ships and eventually I'll look, but setting a large MTU while using a network with a smaller MTU just isn't going to work well. What's the complaint here - that it's slow? Given all of the extra copying and manipulation I am not surprised at that.

How it's supposed to work is described in RFC 1201.

And it *can* work very well, see this combo: SMCARCWS + "Existing ODI Driver" + Windows TCP/IP stack.
When uploading from Windows, I can see "length 1460" packets at the server - obviously the client has MTU 1500, and it works fast.

MTU 1500 is bad eg. with this combo: SMCARCWS + ODIPKT + mTCP.
mTCP obviously doesn't perform the Datalink Layer Fragmentation.
And, of course, can't blame SMCARCWS.
So, the suspect must be ODIPKT.
ARCETHER and ARCPSF don't do it right, either.

I may try some other shim(s) in the future, but for now, the recommendation for using mTCP with Arcnet is:
Leave MTU at the default of 576, or even decrease it to 504.

Is Arcnet suitable for IPX multiplayer gaming?

I've installed NetWare Client for this board:

...ran Doom, and...
SUCCESS - it just works.

Of course, full NetWare Client isn't necessary, only the following files:
LSL.COM
NET.CFG
TRXNET.COM
IPXODI.COM

And yes, Novell wasn't just NE1000 and NE2000 - they also had a series of Arcnet cards: