From Dave Barker on 08 Sep 1998
I'm trying to setup a Linux RH 5.0 box as a dial in server using a DigiBoard C/X host adaptor and a 16 port C/Con 16 Concentrator. What I'd like to know is:
Does Linux support Software controlled Serial Ports, meaning the current attempt has been to set up a 15MB dos partition as the boot, and install the DOS drivers from Digi, and then add the com ports into linux?
The question (as stated) is flawed. On a PC all multi-port serial boards require some form of software to control them (since the BIOS/firmware only supports 4 COM ports). In addition the BIOS support for COM ports is extremely limited and slow --- so all communications software (under DOS, Windows, OS/2, Linux and other forms of UNIX, etc) have bypassed the firmware and used direct access to the I/O ports that control the serial ports as well as those that actually carry the serial data).
So, a more reasonably restatement of your question might be:
Can Linux use the DOS drivers supplied by Digi?
... that answer is "no." (It is also "no" for NT, other forms of UNIX, OS/2 and probably for Win '95/'98 as well).
Device drivers are generally not portably between operating systems. The interface between an OS kernel and its device driver is typically unique for each OS. There has been some discussion about creating a portable PC device driver specification --- to allows SCO, Solaris, Linux, and *BSD drivers to share (at least some) device drivers. That will probably never happen --- and even if it does it will probably never extend to non-Unix-like operating systems.
Now, regarding the broader question:
Does Linux support the Digi C/X intelligent serial port subsystem?
When I last corresponded with Digi about this they assured me that they would have native Linux drivers by the end of that summer. That was over a year ago. I did check back on their web site a couple of months ago and it didn't seem to indicate that they'd ever delivered on this promise.
The obvious thing to do would be to contact their support staff and ask for native Linux drivers. It may be that their web site is out of date, or that my efforts t weed through their pages was inadequate (the bigger the company, the worse their web site).
[ I dunno about the Digi International site, (which is being redesigned right now) but the Linux Digiboard Page might be useful, even though it's rather old. -- Heather ]
Next if this would work in theory what is the proper way to go about setting the serial ports up?
The "proper way" would be to use the device drivers that work with your OS. Another way, might be to run the DOS drivers under 'dosemu' (configuring that with sufficient access to the hardware and I/O permissions map that the Linux kernel will let it drive the serial board). However, that would only allow DOS to access the devices.
In the project where I initially contacted them I was using an operating system called TSX-32 (by S&H systems: http://www.sandh.com) --- and the TSX-BBS (also by them).
This package is a 32-bit multi-user commercial (closed source) OS that's modeled after the old TSX-11 and RSX-11 (a predecessor to VMS on the PDP-11 platform). It also runs a decent DOS emulator and the BBS has some nice features that make it more scalable than any other that I'd seen
(I've run Galacticomm MajorBBS and eSoft TBBS systems which used to be limited to single CPU's, had no TCP/IP support, no end-user scripting facilities, limited support for doors, and little or no support for intelligent serial hardware --- such that 255 was about the maximum --- PCBoard as limited to about 4 to 8 lines per PC --- and you needed a Netware server to cluster those. TSX-BBS can handle 250 lines per server and multiple servers can peer over TCP/IP for a potential of thousands of lines).
Obviously Linux (and other forms of Unix) have that sort of scaleability --- given the drivers. There are some big Unix/Linux BBS' out there (like MMB "Teammate" and a native port of Galacticomm's BBS --- renamed to something like "WorldPort" --- though I don't remember the details).
My enthusiasm for TSX-BBS has waned a bit (they aren't getting out the updates that I'd hoped for). However, that's a non-issue since I left that position long ago and no longer have to maintain any BBS' (and the whole dial-up bulletin board system phenomenon seems to have waned almost as much as UUCP).
I'm really in a bind here, and could use any help I can get! Thanks in advance David Barker email@example.com
I would beat up on Digi --- and, if they don't satisfy your needs --- consider one of their other models (a number of them do support Linux) or Rocketport, Equinox, Comtrol, Cyclades, Stallion, or other vendors of multi-port serial hardware that will support Linux.
Naturally I understand that this may entail major reworking of your plan. The C/X is the only system that I know of that allows you to connect 250 ports to a PC using only one bus slot. You might have to rework your plan to use multiple Linux systems, each with multiple serial port board, and configure those as "terminal servers" (have them binding the incoming serial/phone connections into 8-bit clean rlogin/telnet sessions to the master server.
Of course you could also look at traditional terminal servers. These are router-like devices that do precisely what I've described (often with support for their own authentication --- RADIUS and/or various versions of TACACS, and support to provide PPP and/or SLIP instead of the rlogin/telnet like session that would be used for dial-up terminal use.
Naturally to give you better advice and more specifics I'd have to know more about your requirements and less about the particular problems you're encountered with your currently proposed solution. All I can currently guess about your requirements is that you need support for a bunch of serial lines (you said "dial-in" so I can also guess that a bunch of modems are involved).
If you already purchased the C/X and you already selected Linux for this project then shame on you --- you really need to do requirements analysis before committing to various implementation details (specific hardware and software). (If you're just stuck with some stuff you had laying about for a skunkworks project --- then my condolences; you might need to negotiate some funding for it).