sean(at)walbran.org and Marvin Stodolsky stodolsk(at)erols.com
quiThis is the Linux Linmodem HOWTO document. It is intended as a quick reference to help you find out if there is a way to get your (so-called) winmodem working under Linux, and, if so, how to do it. You should understand from the outset that there may well be no support for your winmodem: at this time, there is limited support for such modems, often in the form of vendor-created but vendor-unsupported, binary-only kernel modules; however, a small number of open-source projects exist. For the most up-to-date information about available Linmodem drivers, visit Rob Clark's site and the Linmodems.org site. General modem issues, such as IRQ settings and dialup scripts, are dealt with much more thoroughly in the more general Modem-HOWTO, Serial-HOWTO, PPP-HOWTO, and other related HOWTOs available at the Linux Documentation Project site.
Copyright (c) 2000 by Sean Walbran, Marvin Stodolsky
Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be fowarded to the document maintainer. You may create a derivative work and distribute it provided that you:
If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.
Use the information in this document at your own risk. We disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.
All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. In particular, since the term "Winmodem" is a trademark of US Robotics/3Com, we use the term "winmodem" here as does Rob Clark: to be read as "Winmodems(tm), host-based modems, HCF-modems, HSP-modems, and all similar modem-like hardware." Linux is a trademark of Linus Torvalds.
Naming of particular products or brands should not be seen as endorsements.
It are strongly recommended to make a backup of important and/or relevant files before any installation procedure.
A large amount of information contained in this document comes a variety of great sources such as Rob Clark's site, Linmodems.org, and the mailing lists there, and Werner Heuser's Mobilix pages.
Thanks to Mark Spieth (mark(at)digivation.com.au) for discussions, advice, the contribution of his "fixscript" for module kernel version editing (originally to the Linmodem mailing list here, and newer versions made available at http://www.test.dclabs.com.au/linmodem/fixscript), and his great work on finding the ppp incompatibilities.
Thanks to Willie Green willjr(at)lcc.net for his contribution of the ESS modem information.
Thanks to Werner Heuser wehe(at)snafu.de for tips on setting serial
parameters with older kernels, and a number of other good points.
Other individual credits are given in the body of the text where appropriate.
This document itself was created using the SGML HOWTO template created by Stein Gojen, as described in the HOWTO-HOWTO. site.
The most recent HTML version of this document is available at http://walbran.org/sean/linux/linmodem-howto.html, SGML at http://walbran.org/sean/linux/linmodem-howto.sgml, and some other formats in the same directory.
Do you have a Linmodem which works, but is not described here? Are you
developing a driver? Do you think something in this document is incorrect
or misleading? Do you think that your or someone else's work has been
used here but not appropriately credited? Please don't hesitate to
email me at sean(at)walbran.org with corrections and suggestions.
A Linmodem is the Linux implementation of a "winmodem" (see disclaimer). These devices are 'less than' a modem in the sense that they depend on software to perform, to a greater or lesser extent, the functions traditionally handled by modem hardware. The rationale for this is, of course, that software is cheaper than hardware, and can be upgraded/expanded/improved without the use of screwdrivers (usually); however, for the modem to function at all, one requires software that can run on one's preferred operating system.
At the time of this writing, only a few winmodems will work under Linux:
There exists a driver at
http://www.olitec.com/pci56kv2.html which was only
recently (Sept. 2000) "discovered" by Denis Havlik (denis(at)mandrakesoft.com).
The page is in French,
but the installation commands are given on the page in boldface red text.
Essentially, download the package, unpack it with tar -zxvf, and run
the installation script ins_all. Some things already known about the driver include:
.inf file for some other phone systems
to the linmodems mailing list at
http://linmodems.org/cgi-bin/ezmlm-cgi?1:msp:1773:nlifphijcfgckncagkpa. Also, you can try disabling dial-tone detection with your dialer.
Mikhail Moreyra has written a GPL'ed driver for the CL-MD5620DT chipset which can do up to 33.6 kbps; however, this is alpha software and should be treated with due care. The driver can be obtained at http://linmodems.org/CLModem-0.3.0.tar.gz. Recently, Gabriel Gambetta (ggambett(at)internet.com.uy) issued a patched version of the driver to allow standard AT modem commands; you can get this version at Rob Clark's site here.
In addition, Rob Clark's site reports that Ambient may release Linux drivers for their MD563X HaM modems at http://www.ambient.com at some undetermined point in the future.
There exists a manufacturer-unsupported, binary-only kernel module compiled for the 2.2.12 Linux kernel released for Lucent LT (PCI and ISA) modems. As discussed below, this module will work with minor complaints under kernel 2.2.14, and with some additional effort under kernels up through 2.2.17, but the module does not insert into the (still experimental) 2.4.0-test10 kernel. The driver can be obtained at http://linmodems.org/linux568.zip
Some open source tools for use with Lucent modems are available at http://www.close.u-net.com/ltmodem.html. Pavel Machek writes that "It is not too useful, however: it is a hardware driver, and without a v.34 protocol stack, you can't connect to your ISP. It is enough to turn your Lucent winmodem into an answering machine, however."
Binary drivers for PCI, AMR, and Zoltrix Phantom can be found at http://www.kcdata.com/~gromitkc/winmodem.html#drivers
Binary drivers for ES56T-PI (PCI) and ES56V-I (ISA) can be obtained at
A request for comments was posted by a 3Com official about the possible demand for a binary-only driver for their miniPCI combination NIC/winmodem on the Linmodems.org mailing list. Though to my knowledge no driver has yet been released, Werner Heuser's miniPCI page has more information and links.
The information about installed hardware using commands including:
cat /proc/pci and lspci pnpdump and isapnp cardctl ident dmesg | more and cat /proc/interrupts The Device Manager under Windows can provide similar information, but it should be
noted that a manufacturer will often simply put its brand name on a built-in modem, so
this information may not be as useful as you might hope (e.g., what chipset does
a "Compaq Internal 56k" modem have?). Additional information may sometimes be
obtained by making a modem log. This is implemented under MS Windows as a check box
option within the Dial Up Networking graphics menus. The file produced is
C:\WINDOWS\MODEM.LOG. It will contain the modem initialization strings,
and perhaps also the name of the modem configuration file, which may also contain
other useful information.
If already running Linux, you may want to capture diagnostic reports to a text file. This can be easily be done in few ways:
script ModemWork.txt , all
information written to the console is also recorded, until terminated with exit. SomeCommand >> ModemWork.txt where the double >>
specifies add text to the end of ModemWork.txt, rather than overwriting it.
If you know the precise name of your modem, you can try searching the large Linux Modem Compatibility database at Rob Clark's site. The color/letter code on the left side of the table will indicate if your modem is known to function or not under Linux. The code "LM" indicates a Linmodem, and the modem notes should indicate which driver you need. A "WM" means it's a winmodem, but no support is known to exist. Be careful not to assume that modems with similar names will contain the same chipsets, or will necessarily behave similarly whatsoever! Your WhizBang LX56 and your friend's WhizBang GT56 could have entirely different innards.
If you do not know the precise name of your modem, you can search based on the identification number of the modem: on every modem there must be printed a registration number, which may either be the board producer's designation, or, alternatively, an FCC registration number. An example photo of such an ID number on a modem board can be found at http://www.kcdata.com/~gromitkc/fcc1.jpg on Rob Clark's site. You can then proceed to use your web browser to search his table of modems and FCC ID's to obtain chipset/driver information. Alternatively, you can directly search the US Federal Communications Commission (FCC) database at http://www.fcc.gov/oet/fccid/. Read the directions carefully, and be careful not to confuse O (the letter) with 0 (the number), and other possible mixups.
You may not be able to obtain the FCC ID number if you have a laptop which you prefer not to open up, or are looking to buy a particular machine and the vendor has not been polite enough to provide you with the information nor a sample box for you to take apart and play with. In these cases, you have a few options:
There is a quick test that can be run from a floppy disk before you commit to buy the the just advertised WhizBang PC/Laptop. The intent is to use Linux itself to check whether the pre-installed modem is supported under Linux.
There are Rescue floppies for Linux maintenance. Most boot up a RAM disk, without "touching" the hard disks unless/until specifically commanded to. A collection of the available
Linux modem drivers can be previously collected on a separate floppy.
A running kernel will generally not accept a hardware dependent module unless
the compatible hardware is present. Thus if lsmod displays a successful
insertion after:
insmod /mnt/modem-driver1.o
or at worst with forcing
insmod -f /mnt/modem-driver1.othere is a good chance that the modem will serve under a full Linux installation. This insertion test can be repeated in turn with all the available modem-driverN.o, and hopefully one will succceed. For this test the DOS formatted floppy disk with drivers is first made accessible with:
mount /dev/fd0 -t msdos /mnt
and drivers can be listed with:
ls /mnt
There is a caveat that this test may fail merely because of mismatches
between kernel sources versions of the modem.o and the kernel being used
in the test. Kernels on the Rescue disks should thus be version matched
as closely as possible with the that of the modem-driver.o. The Lucent
ltmodem.o and Archtek esscom.o modules were compiled under
kernel-sources-2.2.12, so, for their tests, the kernel on the Rescue
floppy should best be replaced. One suitable Rescue disk is made from the
Debian resc1440.bin by rawrite.exe under DOS. It carries instructions
from substituting and properly activating its kernel and some suitable kernel
has been compiled. See the contents of
http://walbran.org/sean/linux/stodolsk/ for resources and detailed instructions.
The relevant Linmodem driver modules to go on the secondary disk are listed above.
There is another caveat, however: I (Sean) tried this out with a stock Red Hat 6.2 distribution, and found that it gave me no complaints whatsoever when I insmod'ed the esscom.o module, despite the fact that I have the Lucent chip modem. Similarly, ltmodem.o insertion was achieved with an ESS modem installed by Marv Stodolsky, but ininitiation of a PPP session hung the PC. These mismatches probably occur because of similarities in the ESS and Lucent chips which fool the kernel diagnostics. Thus a successful insertion does not definitively identify which chip your modem carries.
All of the drivers listed here are released as kernel modules; therefore, you must be sure to have a kernel which supports module insertions. 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
This is a newly recognized factor as of Oct. 24, 2000 (and should be considered anecdotal until information on further hardware/software combinations is gathered). Marv Stodolsky has observed that with the Lucent modem, sound support must be enabled in the kernel (support via sound modules is OK), or else a dail-in session utilizing the ltmodem.o driver aborts/hangs when the ppp protocol is initiated. The combination of OSS software providing all audio support (with a kernel without sound compiled in) failed to support the ppp protocol through the ltmodem.o driver. How broadly valid these "sound" factors for other Linmodems/Audio_cards remains to be clarified.
If you have an ISA Plug-n-Play modem, 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, in this case at least, it was necessary to leave
the #(ACT Y) commented out. If it doesn't work for you one way,
try it the other.
/etc/isapnp.confpnpdump 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 than cat /proc/pci gives
for cards with a PCI interface, utilities within the software package
pciutils are useful, such as scanpci and lspci.
insmod -f, Fixscripting, and ppp.oAs of the writing of this document, source code is only available for the Ambient Technology
driver. Generally, 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 most modem/modem_chip vendors
have not yet chosen to release source-code versions of their drivers. This
would ensure the ability to modify these drivers appropriately as kernel source code
evolves. In particular, it seems that Lucent has violated the Gnu Public License
by deriving their code from the GPL'ed serial.c Linux kernel code, yet
not releasing their source code (see, e.g.,
this Kernel Traffic issue).
In any case, a few binary modules have been coaxed to function
under some later kernel versions, as described below.
A version-matched kernel module is inserted 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 not 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, the
module will be inserted and be to some degree functional. 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 with later 2.2.nn kernels.
However, even forcing fails for kernels compiled from the rapidly maturning 2.4.0 sources.
The depmod commands analyses module dependencies.
The compatility of modules such as ltmodem.o with the running kernel can be checked with:
depmod -e ltmodem.oFor a running kernel-2.2.17, the returned information includes:
"A driver can never work properly if there are unresolved symbols, as it means something is not going to work. Furthermore, it means that that something that would have been called will call something else in the kernel and this could be anything. This is_very_bad."
For modem drivers, simply remove them after termination of an online session with:
rmmod modem-driver
Starting within the 2.2.15 series kernels, a change in the sources rendered the ppp
protocol incompatible with ltmodem.o. This October 2000, Mark Spieth
(mark(at)digivation.com.au) identified the problem and provided a fix, which is
implemented in the kernels provided at
http://walbran.org/sean/linux/stodolsk/kernels.html. A prior
temporary fix required the replacement of the module ppp.o with
one from kernel 2.2.14, as described below.
Mark Spieth has contributed a progressively improved series of "fixscript"
which edits a binary module so that the version mismatch warning is eliminated.
Insertion of the "version fixed" module then proceeds without the forcing flag, i.e. simply
insmod module_name and the "Unresolved symbols in ltmodem.o" complaint
will not be returned by the test depmod -e. It must be emphasized that this
change is almost entirely cosmetic - it is still recommended that the module be used
minimally. This warning haven been given, here is how to use the fixscript, continuing
with the particular example of ltmodem.o.
Make a working directory such as /root/modem. Save the file as fixscript.
View it with less or your favorite text editor to check that DOS hard stops were not
accidentally acquired. They look like bold M, underlined M, or ^M depending upon your
viewer/editor. NOTE: the viewer more does NOT display these DOSsy stops.
Make the
file executable with chmod +x fixscript. If your running kernel is of version 2.2.17,
generate an edited module with
./fixscript ltmodem.o ltmodem2217.o
A complaint will not be returned by
depmod -e ltmodem2217.o
and insertion is effective with a simple
insmod ltmodem2217.o
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 compensate for a changed kernel interface.
Beginning in the 2.2.15 series kernels, the was a change in the source code causing an incompatibility between the PPP protocol and drivers ltmodem.o and esscom.o. Mark Spieth traced the problem to:
/usr/src/linux/include/linux/tty.h
with the fix requiring merely the shift of one line of code line a few lines
down within tty.h. This solution was done initially for 2.2.16 sources,
but Marv Stodolsky, Sebastien Rohaut, and others have
confirmed that it was also effective under 2.2.17 kernel sessions for
Lucent, ESS, and Conexant chipsets.
The patched 2.2.17 tty.h and some 2.2.17 kernel packages compiled with this patch
are available from
http://walbran.org/sean/linux/stodolsk/.
If you want to do the edit yourself, the line to shift is in the structure
tty_struct within include/linux/tty.h; it has an extra member
poll_wait in later kernels.
Move this member to the bottom of the structure and the remaining offsets
will then be the same as those in <= 2.2.15, and thus be compatible with
the precompiled kernel module. You will need to recompile your kernel
and modules after making this change to the source.
This is the much preferred alternative to an earlier trick, which does not require the kernel recompilation: Christoph Hebeisen (cth(at)sfu.ca) reported that use of ppp.o version 2.2.14 rather than that of version 2.2.16 provided functionality under 2.2.16 kernels. Willie Green (willjr(at)lcc.net) confirmed that this trick works also with the ESS module. After simple insertion of a supporting version-matched module:
insmod slhc
the mismatched ppp.o from 2.2.14 source is inserted
insmod -f ppp.o
This forced insertion is certainly less desirable than the kernel source change.
As of October 2000, none of the binary linmodem drivers are functional with the kernels compiled from the rapidly maturing 2.4.0 sources. Hopefully, the modem chip manufacturers which provided drivers for the 2.2.nn sources, will do so again for the 2.4.nn sources. Again, the much preferred solution would of course be to have the driver code source for co-compilation with new kernels, in particular the source for the Linux serial.c-derived Lucent module, which, under the GPL, would appear to be legally required to be open-sourced.
Installation instructions are given for the binary drivers described above, since the accompanying documention is scant (if existing at all) and can be very misleading. Installation of open-source drivers is not covered here, since it is usually better described by its own documentation, and varies more dramatically from package to package and from time to time.
Installation instructions for the Conexant driver are given, to the extent that they are known, above. This driver has not yet been thoroughly explored.
You may wish to use the installation script which may have accompanied your driver instead of following the instructions given here.
You should read through the instructions given below before beginning, to get a feeling for what's going on and where you might run into problems.
If your modem is an ISA PNP modem, make sure that the PNP resources have been appropriately allocated using isapnptools. (See "ISA Plug-n-Play" above.)
See "Which Linmodem hardware is supported?" above for the approprate URL for the driver for your hardware.
If necessary, unpack the driver package in an empty directory
with unzip (if .zip),
tar -zxvf (if .tar.gz ), etc. The files present should
include binaries with names like some-driver.o (e.g., in the example
in the next step, the module is named ltmodem.o).
A trial insertion of the module is a good first check to do. Though its results are not necessarily indicative of your final success, it is a fair indicator of whether the remaining steps will be worth your time.
In the directory in which the files were unzipped, perform the following
steps, replacing ltmodem.o with the name of the appropriate module(s)
for your modem:
First, try to simply insert the module with:
insmod ltmodem.o
There may be a complaint such as:
kernel-module version mismatch ltmodem.o was compiled for kernel version 2.2.12-20 while this kernel is version 2.2.17.If so, try forcing the insertion with:
insmod -f ltmodem.oHaving done this, check for successful insertion into the kernel with:
lsmodwhich will, if insertion was successful, display a list including
ltmodem.o
such as:
Module Size Used by ltmodem 453200 0 (unused) nls_iso8859-1 2268 1 (autoclean) nls_cp437 3744 1 (autoclean) vfat 9052 1 (autoclean) fat 29248 1 (autoclean) [vfat]: ...
If the module (ltmodem) was not inserted, there is an
outstanding problem. The some-driver.o may not
be matched with the modem hardware; the differences between
the sources from which the kernel and module were compiled
may be too great; or, your module may require another module
to be loaded beforehand (some PCTel packages have two modules;
try reversing the insertion order of the two?).
Before abandoning the current effort
entirely, a more closely version matched kernel could be
installed and tested. Source files for
Linux kernels can
be downloaded and already compiled kernels are available
with many Linux distributions.
If the insertion was successful, it is worth proceeding further. Basically the following are just more elegant alternatives to:
insmod -f modem-driver.o
without any change in core functionality. For definitiveness, the prototype usage of ltmodem.o continues.
The full name of the alias configuration file differs among Linux distributions, but there is always one with the functionality now described. In Debian/Corel/Stormix distributions it is /etc/modutils/aliases wherein a line could be entered
alias ltmodem "-f ltmodem.o"
This change is carried to /etc/modules.conf by:
update-modules
which is read upon boot up.
On Linux systems, modem modules are stored in sub-directories such as
/lib/modules/2.2.17/misc. The module can be copied there:
cp ltmodem.o /lib/modules/`uname -r`/misc/ltmodem.o
where `uname -r` specifies the version of the active kernel, It is preferentially used because some kernel installations do have less usual version names such as 2.4.0-test8. Thereafter, forcing will be done automatically whenever ltmodem.o is called.
Use the fixscript as described above to generate ltmodem2217.o if your current kernel is of version is 2.2.17. To allow use of the same ltmodem calls after kernel changes:
cp ltmodem2217.o /lib/modules/ltmodem2217.o
ln -s /lib/modules/ltmodem2217.o /lib/modules/2.2.17/misc/ltmodem.o
The latter command puts the symbolic link /lib/modules/2.2.17/misc/ltmodem.o in the regular module search path, so that the simple command:
insmod ltmodem
will thereafter work. This symbolic link also protects the binary ltmodem2217.o from inadvertent deletions of modules which may accompany kernel+modules upgrade processes. But remember that, after such upgrades, remaking the symbolic link may be necessary.
There are apparently two types of PCTel module package around.
/lib/modules/2.2.16.
With such a package, if you are running a kernel more recent than 2.2.16, you should try the "fixscript" method used with the Lucent and ESS modules above, but note that this has not to my knowledge been tried out yet. If you are running a kernel older than 2.2.16, you should consider upgrading your kernel, or else try the fixscripting as well (this is also not guaranteed to work). You should not have to get the 2.2.14 ppp.o module. Please send me a report if you get these to work.
mkdir lib mkdir src mkdir src/module mv *.a lib/ mv Makefile *.c src/module
Now go to the directory src/module and type make. This should generate the module
file pctel.o, which will appear back up in the directory lib. (The driver module is not the file ptmodule.o in src/module!)
The version of the module generated in this way will match your current kernel version.
If not already done, copy the other module file(s) (such as ltmodem.o,esscom.o, and
pctel*.o) into the directory
/lib/modules/`uname -r`/misc/
mknod /dev/ttyS14 c 62 78
mknod /dev/ttyS15 c 62 79
mknod /dev/esscom c 127 1
wvdial.
Note, however, that wvdial is reported to give a kernel panic on ppp-off
with this module under kernel 2.2.16 (and possibly others). This may not be a general situation, however.chgrp uucp /dev/ttyS14 chmod 666 /dev/ttyS14Group definitions can be modified in
/etc/group.
ln -s /dev/yourdevicefile /dev/modem
Note: if you chose to skip the "Align the module and kernel versions" step above, you may need to use "insmod -f" here.
insmod ltmodem
insmod esscom
insmod pctel
Your Linux system will in many cases need to be informed of
the addition of the new "serial" device /dev/ttyS14 or 15.
The drivers available tend to have been compiled for a kernel version 2.2.x, with x in the teens. However, if you are for some reason unable/unwilling to update your kernel, Werner Heuser (wehe(at)snafu.de) points out the following tips for older kernels:
With 2.0.x kernels, the serial ports
are defined in the serial driver source itself, i.e.
/usr/src/linux/drivers/char/serial.c; after 2.1.98, these
moved to /usr/src/linux/include/asm-i386/serial.h and require
CONFIG_SERIAL_MANY_PORTS, MULTIPORT and SHARE_IRQ to be set during
kernel configuration. You should modify the appropriate line
for your device file, i.e. either of
/* UART CLK PORT IRQ FLAGS */
...
{ 0, BASE_BAUD, 0x000, 0, 0 }, /* ttyS14 (spare; user configurable) */
{ 0, BASE_BAUD, 0x000, 0, 0 }, /* ttyS15 (spare; user configurable) */
to read something like
{ 0, BASE_BAUD, 0x0260, 3, STD_COM_FLAGS}},
with the appropriate port/irq for your hardware.
When you boot the new kernel with these changes,
you should see a message like the following:
Serial driver version 4.13 with no serial options enabled tty00 at 0x03f8 (irq = 4) is a 16550A tty14 at 0x0260 (irq = 3) is a 16550A
With more modern Linux kernels, script files such as
/etc/serial.conf and the program setserial
are generally used to govern the parameters of serial ports; your
configuration will likely have to be modified to accommodate the new device, though
this apparently depends on your kernel/distribution of choice.
The best reference for such modifications is David S. Lawyer's excellent
Serial HOWTO, in particular the section on
Setserial, where he notes, in particular, "Don't ever use setserial
with Laptops (PCMCIA)". The documentation with your distribution should
provide you with more information on the particular defaults and
initialization scripts used.
As an example, Sean's laptop with the Lucent LT modem, running
Red Hat 6.2/kernel 2.2.14-5, required no modifications to the (
in fact nonexistent) /etc/serial.conf whatsoever.
With Marvin's PCI Lucent winmodem with a Debian installation, however,
the following
section is needed in the file /etc/serial.conf:
# These are two spare devices you can use to customize for # some board which is not supported above.... # #Lucent Modem driver version 4.27.5.66 # ltmodem.o was compiled for kernel version 2.2.12-20 # with MANY_PORTS MULTIPORT SHARE_IRQ enabled # ttyS14 at 0x0260 (irq = 3) is a Lucent /dev/ttyS14 uart 16450 port 0x0260 irq 3 #/dev/ttyS15 uart XXXXX port XXXX irq X # These are the ports used for either the Usenet Serial II # board, or the Boca Board 4, 8, or 16 port boards.
Whatever your particular configuration, conflicts for interrupt (IRQ) assignments are generally to be avoided. Information on your serial port properties can be displayed with:
setserial -agv /dev/ttyS*which returns information like:
/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test session_lockout
/dev/ttyS14, Line 14, UART: 16950/954, Port: 0x0260, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
At this point you probably want to try dialing out with a simple terminal
program like minicom.
The name and location of these scripts depend on the particular Linux distribution (among Redhat, Debian, Suse and many others) and the particular software mediating the dialup (such as kppp and wvdial). Many distributions/dial-up software have a configuration utility which will request your input and then automatically generate the dial-up scripts. The minimum information required is:
If you have trouble, consult the documentation of your ppp dialer and/or the PPP-HOWTO. Example scripts for the particular example of pppconfig with Debian are given in the appendix.
Try to connect to your ISP with the ppp dialer.
Congratulations!
Dang!
See the Troubleshooting and FAQ sections of this howto for some ideas on how to fix it.
To avoid having to insert the module(s) in the kernel every time you want to dial in, see the appendix section "Coincident insertion and removal of ppp related modules."
Probably not. Please see the section "Which Linmodem hardware is supported?" above, and check the Linux Modem Compatibility database at Rob Clark's site.
setserial -agv /dev/ttyS*, does it return something
sane for your device file? If not, see the "Modifying your serial port configuration"
section above.
Unresolved symbols are a true danger of version mismatching and are, in general, bad, but are also almost inevitable with binary modules. If the fixscript reports unresolved symbols, or the module does not work despite the unresolved symbols, you may be out of luck with that kernel/module combination; however, a few common cases involve symbols like:
slhc_xxxx: You probably need to insmod the slhc
module before inserting the modem/ppp modules.printk, jiffies: Your kernel may be compiled with
SMP enabled. None of the binary modules are known to be SMP-safe, and will
probably only work on a single-processor machine with a single-processor
kernel, i.e. SMP disabled. You should try recompiling your kernel or
otherwise obtaining a version with SMP disabled. (Thanks to
Tom Reinertson (treinertson(at)uswest.net)) tty_xxxx with esscom.o:
Earlier fixscripts were not able to handle the version-specific symbols
in this module. More recent versions are available at
http://www.test.dclabs.com.au/linmodem/fixscript)
which should be able to fix this module as well.
This is an often-reported problem that may have a few, or no, solutions:
kppp will give this error, while an alternative like wvdial
does not, for the same modules and hardware. You may wish to try a different
ppp dialer and see if that helps. Most Linux distributions do deposit a kernel configuration file along with the kernel. For Debian related distributions, it is the file
/boot/config-versionThe positive choices can be quickly displayed with:
grep SOUND /boot/config-version |grep -v notFor the specific example of a 2.2.17 version:
# grep SOUND /boot/config-2.2.17 |grep -v not CONFIG_SOUND=m CONFIG_SOUND_OSS=m CONFIG_SOUND_SB=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_YM3812=m CONFIG_SOUND_VMIDI=m CONFIG_SOUND_YMPCI=m CONFIG_LOWLEVEL_SOUND=y
Either CONFIG_SOUND=m or CONFIG_SOUND=yes would show that the kernel has sound support, as would simple sound output.
If none of these helps, you may wish to consider trying to use a kernel version which is closer to the module. Otherwise, try the mailing list at Linmodems.org for help.
There are a couple of possible solutions to this, neither of which may work:
If all seems lost, please see the section "Troubleshooting", below , and consider sending a message with the complete information described there to the mailing list at Linmodems.org.
Probably somebody on contract to the manufacturer, who probably does not have the authority the update/release/change the source code, and who probably doesn't have time to reply to your email in any case. See, for example, http://lwn.net/1999/1209/a/lucent.html
So you've read through this document, the Modem-HOWTO, and the PPP Howto, are pretty sure that your modem matches one of the drivers available, but it still doesn't work? There are a number of points in the process at which something could break down. Marvin Stodolsky writes:
Linux generally maintains records of networking connections which are very useful in troubleshooting problems. Their particular filenames vary with both the Linux distribution and Dial-in software. For both your own trouble shooting and queries for help to a list, it will be useful if you accumulate the information requested below. As Root, start a script record named say, Modem test. After this script is terminated with "exit," copy it out of your Linux partition for transmission to the List which may aid you. Change to the directory in which the modem install scripts are located. Below, # are explanatory comments.
# start the recording, script ModemTest.txt # type in as much info on your Modem card as you have echo winmodem name, manufacturer, designation, and chip if possible # this gives your current kernel version uname -r # this gives information on your serial ports setserial -agv /dev/ttyS* # this information on your interrupts (irq) cat /proc/interrupts # show the contents of your module installation script (insert script name): cat ScriptName # Check if your script is executable: ls -l ScriptName # a response is OK if it has "x" such as below: # -rwxrw-rw- 1 root root 654 Jan 6 2000 ltinst # otherwise make it executable with: chmod o+x ScriptName # verify with ls -l ScriptName # if ScriptName has not been successfully run before under this kernel # run it with: ./ScriptName # what is the symbolic link /dev/modem set to: ls -l /dev/modem # What is the DeviceName specified in the ScriptName (/dev/ttyS14 or ...?) echo DeviceName # what is your modem driver name? Something like DriverName.o # with the ".o" indicating it is a compiled binary echo This is my DriverName.o # if should have been inserted in the Modules Path # Try to display it there with: find /lib/modules | grep DriverName # Is DriverName among the modules installed in the running kernel? lsmod # if not try a simple insertion: insmod ./DriverName.o # or if it was in the Modules Path, the following will suffice: insmod DriverName # check for insertion: lsmod # if not inserted, try forcing: insmod -f ./DriverName # list your inserted modules again. lsmod # If DriverName is NOT listed, # their is an incompatibility between modem hardware, driver and kernel. # Further effort will be of No use. # If DriverName is listed, let's do a bit more information. # You may first wish to rerun the configuration utility # used to setup dial-in connections for your Linux installation. # Remember to edit your PassWord from this record later. # You will probably be queried for the following information # which you should have ready: #Port to be used (/dev/modem or /dev/ttySn),Dial-inNumber, UserName, PassWord. # Run your configuration utility. YourSetUpConf # To stop recording exit
If dialin was not successfull, append to this a record from your log file. As an example, a section of a /var/log/syslog from a Debian Linux system is below.
Aug 21 08:35:41 koala kernel: CSLIP: code copyright 1989 Regents of the University of California Aug 21 08:35:41 koala kernel: PPP: version 2.3.7 (demand dialling) Aug 21 08:35:41 koala kernel: PPP line discipline registered. Aug 21 08:35:42 koala kernel: registered device ppp0 Aug 21 08:35:42 koala pppd[1539]: pppd 2.3.11 started by root, uid 0 Aug 21 08:35:43 koala chat[1545]: abort on (BUSY) Aug 21 08:35:43 koala chat[1545]: abort on (NO CARRIER) Aug 21 08:35:43 koala chat[1545]: abort on (VOICE) Aug 21 08:35:43 koala chat[1545]: abort on (NO DIALTONE) Aug 21 08:35:43 koala chat[1545]: abort on (NO DIAL TONE) Aug 21 08:35:43 koala chat[1545]: abort on (NO ANSWER) Aug 21 08:35:43 koala chat[1545]: send (ATZ^M) Aug 21 08:35:43 koala chat[1545]: expect (OK) Aug 21 08:35:43 koala chat[1545]: ATZ^M^M Aug 21 08:35:43 koala chat[1545]: OK Aug 21 08:35:43 koala chat[1545]: -- got it Aug 21 08:35:43 koala chat[1545]: send (ATQ0V1E1S0=0C1D2S11=55+FCLASS=0^M) Aug 21 08:35:44 koala chat[1545]: expect (OK) Aug 21 08:35:44 koala chat[1545]: ^M Aug 21 08:35:44 koala chat[1545]: ATQ0V1E1S0=0C1D2S11=55+FCLASS=0^M^M Aug 21 08:35:44 koala chat[1545]: OK Aug 21 08:35:44 koala chat[1545]: -- got it Aug 21 08:35:44 koala chat[1545]: send (ATDT17574238738^M) Aug 21 08:35:44 koala chat[1545]: expect (CONNECT) Aug 21 08:35:44 koala chat[1545]: ^M Aug 21 08:36:16 koala chat[1545]: ATDT17574238738^M^M Aug 21 08:36:16 koala chat[1545]: CONNECT Aug 21 08:36:16 koala chat[1545]: -- got it Aug 21 08:36:16 koala chat[1545]: send (\d) Aug 21 08:36:17 koala pppd[1539]: Serial connection established. Aug 21 08:36:17 koala pppd[1539]: Using interface ppp0 Aug 21 08:36:17 koala pppd[1539]: Connect: ppp0 <--> /dev/ttyS14 Aug 21 08:36:18 koala pppd[1539]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x64acd5df> <pcomp> <accomp>] Aug 21 08:36:18 koala pppd[1539]: rcvd [LCP ConfReq id=0x1 < 00 04 00 00> <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp> < 11 04 05 f4> < 13 09 03 00 c0 7b 7d 08 8c>] Aug 21 08:36:18 koala pppd[1539]: sent [LCP ConfRej id=0x1 < 00 04 00 00> < 11 04 05 f4> < 13 09 03 00 c0 7b 7d 08 8c>] Aug 21 08:36:18 koala pppd[1539]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x64acd5df> <pcomp> <accomp>] Aug 21 08:36:18 koala pppd[1539]: rcvd [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp>] Aug 21 08:36:18 koala pppd[1539]: sent [LCP ConfAck id=0x2 <mru 1524> <asyncmap 0xa0000> <auth pap> <pcomp> <accomp>] Aug 21 08:36:18 koala pppd[1539]: sent [LCP EchoReq id=0x0 magic=0x64acd5df] Aug 21 08:36:18 koala pppd[1539]: sent [PAP AuthReq id=0x1 user="stodolsk" password=<hidden>] Aug 21 08:36:19 koala pppd[1539]: rcvd [LCP EchoRep id=0x0 magic=0x0] Aug 21 08:36:19 koala pppd[1539]: rcvd [PAP AuthAck id=0x1 ""] Aug 21 08:36:19 koala pppd[1539]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>] Aug 21 08:36:19 koala kernel: PPP BSD Compression module registered Aug 21 08:36:19 koala kernel: PPP Deflate Compression module registered Aug 21 08:36:19 koala pppd[1539]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] Aug 21 08:36:19 koala pppd[1539]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.65.9.14>] Aug 21 08:36:19 koala pppd[1539]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.65.9.14>] Aug 21 08:36:19 koala pppd[1539]: rcvd [IPCP ConfNak id=0x1 <addr 207.172.212.104>] Aug 21 08:36:19 koala pppd[1539]: sent [IPCP ConfReq id=0x2 <addr 207.172.212.104> <compress VJ 0f 01>] Aug 21 08:36:19 koala pppd[1539]: rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Aug 21 08:36:19 koala pppd[1539]: rcvd [IPCP ConfAck id=0x2 <addr 207.172.212.104> <compress VJ 0f 01>] Aug 21 08:36:19 koala pppd[1539]: Cannot determine ethernet address for proxy ARP Aug 21 08:36:19 koala pppd[1539]: local IP address 207.172.212.104 Aug 21 08:36:19 koala pppd[1539]: remote IP address 10.65.9.14 Aug 21 08:36:19 koala pppd[1539]: Script /etc/ppp/ip-up started (pid 1548) Aug 21 08:36:20 koala pppd[1539]: Script /etc/ppp/ip-up finished (pid 1548), status = 0x0
The Lucent driver installation script defaults to having the module loaded upon boot, by appending the line
insmod -f ltmodemto the end of the initialization script
/etc/rc.d/rc.local. If
you have, i.e., an ESS modem, you could replace "ltmodem" with "esscom"
above to have your module automatically loaded on boot. Note, however,
that the initialization scripts differ with different Linux distributions,
so you will need to find, modify, or create the appropriate script(s) for your
particular setup. In addition, Pete (ninjaz (at) webexpress.com) writes
that the initialization order may be important:
Put "insmod -f ltmodem" at the top of /etc/rc.d/rc.sysinit When it's put in /etc/rc.d/rc.local and therefore loaded after the network drivers, the machine hangs for a bit and whenever dialing, yields "NO DIALTONE". Apparently this is due IRQ conflicts relating to the modem getting IRQ 11, instead of IRQ3. When insmod -f ltmodem is in rc.sysinit, everything works fine right off the bat.
Many users prefer to run "lean kernels" which only have the auxiliary modules inserted when necessary. Below are examples of scripts for starting and stopping an online session using a Lucent winmodem with the ltmodem.o driver. It can be applied to many other drivers by simply replacing "ltmodem" with "YourModemDriver".
Modemup:
#!/bin/sh # This script inserts the kernel modules supporting # WinModems using the Lucent ltmodem.o module. # Save as /usr/local/bin/Modemup, then # chmod a+x /usr/local/bin/Modemup # to make it executable. # Since insmod & rmmmod require root permission, permission for an # ordinary User must be given under secure-su or sudo. # # the ltmodem.o driver must be within /lib/modules/kernl-version/misc # # When kernel-source-2.?.?? code becomes available for ltmodem.o , # forced "-f" insertion should be removed from the following line: /sbin/insmod -f ltmodem # and the complaint about version mis-match will also then disappear. insmod slhc # is needed to support ppp insmod ppp # if you are using a ppp.o which is not version matched with the kernel # insmod -f ppp # may be necessary instead echo Loaded kernel modules are: lsmod # An automatic start of the ppp connection is specified # by entering the command that starts your online session such as: # wvdial, pon, ppp-on, kppp or # Whatever ## End Modemup
Modown:
#! /bin/sh # /usr/local/bin/Modown ends a pppd session and does cleanup. # Save as /usr/local/bin/Modown, then # chmod a+x /usr/local/bin/Modown # Starting pppd session related modules are: # ppp_deflate 39108 1 (autoclean) # bsd_comp 3664 0 (autoclean) # ppp 19916 2 (autoclean) [ppp_deflate bsd_comp] # slhc 4200 1 (autoclean) [ppp] # ltmodem 452936 1 # NOTE THAT ltmodem did NOT acquire autoclean status echo " " echo Terminating ppp0 with poff poff sleep 1 # is a pause to let the poff process to terminate, after which /sbin/rmmod ltmodem # removes ltmodem.o module echo " " echo Removed module ltmodem # /sbin/lsmod # echo " " # echo A pause before removing modules ppp_deflate bsd_comp, then ppp slhc sleep 1 /sbin/rmmod ppp_deflate bsd_comp /sbin/rmmod ppp slhc /sbin/lsmod # but doesn't remove the sound related modules called up. Thus echo " " echo Removing sound related module called by LTmodem, soundcore echo " " if not otherwise in use. /sbin/rmmod soundcore echo Remaining modules in kernel-`uname -r` are: /sbin/lsmod # displays remaining modules echo " " ## End Modown
Example PPP scripts configured for a Debian installation by pppconfig are:
/etc/ppp/peers/provider:
# This optionfile was generated by pppconfig 2.0.5. hide-password noauth connect "/usr/sbin/chat -v -f /etc/chatscripts/provider" debug /dev/ttyS14 # port used by the Lucent Winmodem 115200 defaultroute noipdefault user NameAtIP remotename provider ipparam provider
/etc/chatscripts/provider:
# This chatfile was generated by pppconfig 2.0.5. # Please do not delete any of the comments. Pppconfig needs them. # # ispauth PAP # abortstring ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' # modeminit '' ATZ OK ATQ0V1E1S0=0&C1&D2S11=55+FCLASS=0 # ispnumber OK-AT-OK ATDT3019178111 # ispconnect CONNECT \d\c # prelogin # ispname # isppassword # postlogin # end of pppconfig stuff
The following is quoted from one of the PCTel readme files. Thus you can choose the appropriate country code by inserting the module with a parameter as:
insmod pctel.o country_code=7(the "7" being replaced by your country code from the list below). Thanks to Jonathan Emery for pointing out the correct syntax.
Set and report country code.
This driver takes a module parameter to setup the correct country code
setting for various country's telephone networks and it also can report
back the country code been set.
Here are the two versions for country_code selection and reporting:
VERSION #1:
To set country code:
"country_sel_rep sel 7" will sets the country code to 7.
To query the driver for the currently set country code:
"country_sel_rep rep" returns the current country code as the exit code.
VERSION #2:
To set country code:
"country_sel 7" to set the country code to 7.
To query the driver for the currently set country code:
"country_rep" return the current country code as the exit code.
country_code country_name
1 USA
2 FRANCE
3 GERMANY
4 ITALY
5 SWEDEN
6 UK
7 JAPAN
8 AUSTRALIA
9 SPAIN
10 TAIWAN
11 SINGAPORE
12 KOREA
13 SWITZERLAND
14 NORWAY
15 NETHERLANDS
16 BELGIUM
17 CANADA
18 IRELAND
19 PORTUGAL
20 POLAND
21 HUNGARY
22 FINLAND
23 DENMARK
24 AUSTRIA
25 S.AFRICA
26 CTR21 COUNTRIES
27 CHINA
28 MALAYSIA
29 LUXUMBURG
30 GREECE
31 ICELAND
32 NEW ZEALAND
33 BRAZIL