All of the drivers listed here are released as kernel modules; therefore, you must be sure to have a kernel which supports modules. In addition, "module version" support should be enabled to aid the use of kernels and modules which are not version matched, as described further below.
If you use
a kernel from a reasonably recent Linux distribution, module support
is most likely already enabled. If you're compiling the kernel yourself, then you
should already be aware of how to enable modules, via the
Kernel HOWTO
. In any case, you can check to make sure that the following
settings exist in your kernel configuration file
(which is usually found under /usr/src/linux
):
CONFIG_MODULES=y CONFIG_MODVERSIONS=y
If you have an ISA Plug-n-Play modem (such as I do on my
Thinkpad i1411), you will most likely
need to use isapnptools to allocate resources to the modem card.
For this, you need to have isapnptools installed and have an entry in
the /etc/isapnp.conf
file
for the
modem. You should read the
Plug-and-Play-HOWTO
, but if you have no other
ISA devices you're concerned about, basically all you need
to do is:
pnpdump
to generate a prototype isapnp.conf
file based on your system's current resource usage.
(CONFIGURE ACRd119/1 (LD 0 (INT 0 (IRQ 11 (MODE +E))) (IO 1 (SIZE 8) (BASE 0x0100) (CHECK)) (NAME "ACRd119/1[0]{LT Win Modem }") # (ACT Y) ))Strangely, for me at least, it is necessary to leave the
#(ACT Y)
commented out. If it doesn't work for you one way,
try it the other.
/etc/isapnp.conf
pnpdump
output.
(Note that it is probably not necessary to reboot, if you run isapnp
with the right flags. However, it's easiest for the beginner to simply reboot
at this point.)
To access more information on cards with a PCI interface, utilities within the software package
pciutils
are useful, such as scanpci
and lspci
.
insmod -f
, Fixscripting, and ppp.o
As of the writing of this document, source code is only available for the Ambient Technology driver and the Lucent LT user-space tools listed above; the remainder have been released only as precompiled binary drivers. These modules/binaries transparently function only with the kernel against which they were co-compiled. Since the Linux kernel is a dynamically changing beast, it is very unfortunate that the modem vendors have not yet chosen to release source-code versions of their drivers, which would ensure the ability to modify and recompile these drivers for use with improved Linux kernels. In the meantime, however, some luck has been had in coaxing the binary modules to function under some later kernel versions, as described below.
A kernel module generally may be loaded using the command
insmod
module_name. If
the module was compiled under a different kernel than the current one,
insmod
will report the version mismatch and fail to load the module.
One can pass a flag to force the module to load despite the mismatch
as insmod -f
module_name. If the kernel interface the
module uses did not actually change with the kernel version, forcing the
module to load in this way can give you a functioning module. This is the
case with, for example, the Lucent LT modem module ltmodem.o
which, while compiled under 2.2.12, can be forcibly inserted and run without
problems under kernel 2.2.14; however, running it with kernel version > 2.2.15-x
requires the replacement of the module ppp.o
with one from kernel 2.2.14,
as described below.
Mark Spieth (mark(at)digivation.com.au) has contributed a script (see appendix)
which edits a binary module so that the version mismatch warning is eliminated,
allowing module insertion to proceed without the forcing flag, i.e. simply
insmod
module_name. Continuing with the particular
example of ltmodem.o
, generating an edited module with
./fixscript ltmodem.o ltmodem14.oallows insertion under 2.2.14 without mismatch complaint by
insmod ltmodem14
Note, however, that this script does not update the module code to fix any actual kernel API discrepancies, but simply masquerades the module as having been compiled under a different version; i.e., this supresses the symptoms of kernel version mismatch, but does not cure any actual diseases which may exist. The "source code" supplied with some PCTel modules (a small C file) performs similar masquerading when compiled and linked with the binary libraries in those packages, but again does not allow for a changed kernel interface.
Initial attempts to use the Lucent LT modem driver ltmodem.o
under
kernels later than 2.2.15-x failed. However,
Christoph Hebeisen (cth(at)sfu.ca) reported success by
using the modem module compiled under 2.2.12 with a PPP module
(ppp.o) compiled under 2.2.14 with a kernel version 2.2.16.
Willie Green (willjr(at)lcc.net) confirms that this works also with the ESS module.
Marvin Stodolsky (stodolsk(at)erols.com) points out that the same
fixscript described above can be used to version-masquerade the ppp.o
module from 2.2.14 to 2.2.16 as
./fixscript ppp.o ppp14to16.o, thus allowing "soft insertion" of both the ltmodem and ppp modules to obtain a functioning Linmodem under kernel version 2.2.16.
At some point, this chained use of outdated modules will probably reach a breaking point; it would be very surprising, for example, if some complex combination of older modules would allow these binary drivers to work under kernel 2.4 when it is released. The best solution would be, of course, having an open source driver; at the very least, vendor support with binary modules for more recent kernel versions would be useful. The reader is encouraged to do his/her best to support and encourage such developments.