Unfortunately I have a so-called Winmodem in my old Dell Inspiron 4000, and I recently took it upon myself to get this stupid thing working in Debian under kernel 2.6.11. Let's get one thing straight: winmodems are NOT modems (I think I saw a webpage named that). Usually you will send digital signals to the modem which are THEN converted into analog signals by a special chip. Winmodems, on the other hand, are cheaply made. They require your CPU to do this digital to analog conversion rather than passing it off to another piece of hardware. What a waste of CPU power.

Nevertheless, these stupid winmodems are ubiquitous because they are cheap (seriously, how expensive is a REAL modem anyway?)... Fortunately, if your winmodem is run by the Lucent chipset, then there is a good chance that it can work (with a fair amount of tinkering). In my mind I see no reason why these modems don't work "out of the box". The kernel seems seriously lacking in this regard as it should have had automatic support for this 10 years ago (now the day of the modem has passed anyway).

First, I ran "lspci" to see what I have. In my case I received the line (amongst others)

0000:08:08.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)

Yup, a Lucent WinModem. AHHHHH. So now I needed to see if this is a supported chipset. I downloaded the "scanModem" utility from linmodems.technion.ac.il (this website was constantly busy or down for some reason, but I eventually got it). Of course by now I have deleted the package (and the website seems down again) so I can't produce the exact output here. Essentially the tool scanned my system and said that I have a supported Lucent/Agere chipset.

OK, now I grabbed a driver from a link off of that site. Note that this driver MUST be made for the 2.6 kernel (I tried others and they didn't work). In my case I fetched ltmodem-2.6-7alk.tar.bz2 and unpacked it. This tarball contains a README which has some good guidance (although much of it needed to be altered for my Debian situation - I just used the method outlined below).

Before compiling, it was necessary to have the kernel source contained in the directory /usr/src/linux (which was actually a symbolic link to /usr/src/kernel-source-2.6.11). Now keep in mind that in order for this source to actually work, I found that I needed to actually have COMPILED the running (custom) kernel in this directory. Just downloading the source as a Debian package and running a Debian stock kernel didn't work for me. Neither did downloading the corresponding kernel-headers package. In fact, this is probably a good rule of thumb. Any kind of software that you want to compile that is a kernel module will require a /usr/src/linux directory where a custom kernel was ACTUALLY compiled.

Back in the ltmodem source directory I just executed "make" which created the drivers "ltmodem.ko" and "ltserial.ko". In my case I am running kernel 2.6.11, so I copied these two files into the directory "lib/modules/2.6.11/other" (I had to create the "other" subdirectory).

OK, now I needed to let the kernel know that I have some new modules to play with. I ran "depmod" which forced the kernel to read through its modules contained in the /lib/modules/2.6.11 directory and set up dependencies, etc.

These modules would then be automatically loaded at next reboot, although I loaded them manually by typing "modprobe ltserial" (ltserial depends on ltmodem, so that was loaded also). Note that I could have also inserted these modules using "insmod", although I would have been forced to do both of them manually (modprobe takes care of dependencies for me).

OK, at that point the modules were loaded, but the device (the entry in the /dev directory) had not been created. In my case I am using the newer "udev" way of creating devices (this supports hotpluggable devices - i.e. new devices can be created "on the fly") rather than the older "devfs" way (kernel configuration at boot time). Fortunately the README has some udev guidance. In the "docs" subdirectory of the ltmodem tarball I found a file called "ltmodem.rules". This is a set of "udev" rules which tells udev to create the device /dev/modem. Actually, all that this does is symbolically links /dev/modem to /dev/ttyLTM0 (which is created by the modules ltmodem and ltserial). Anyway, I copied "ltmodem.rules" to the /etc/udev/rules.d/ directory. Then I restarted the udev daemon by running "/etc/init.d/udev restart".

BAM!!! The modem now appeared at the device /dev/modem (which is really just a symbolic link to /dev/ttyLTM0). I tested the modem by running "minicom -s". Of course I had to configure minicom to use /dev/modem, but after that I manually dialed a phone number (I chose to bother my friend's house) and verified that the modem WORKED!!!

I noticed that the device /dev/ttyLTM0 is owned by root and the group is the Debian pre-configured "dialout" group. Hence, in order to allow my normal users to access the modem, I added them to the "dialout" group (by editing /etc/group).

Update: I have recently installed a driver for a PCTel Winmodem on my sister's computer. There is NO driver for kernel 2.6 (CHANGED JULY 2005 SEE COMMENT BELOW), although there are claims that there is an experimental driver (it didn't even compile cleanly). The driver for kernel 2.4.27, however, did install as promised. Unfortunately I cannot use "udev" in the kernel 2.4 series, but the PCTel driver installed all of the devices for me.

Double Update: Jeff Trull recently contacted me (end of July 2005) to let me know that he has a new driver written for kernel 2.6! YEAH!!! I won't have a chance to test it until I get back to Utah, but this should allow me to migrate to kernel 2.6 and clear up a bunch of other issues as well!!! Thanks Jeff.

How to set up a PPP connection
As far as command-line dialers, there are the older "pon" and "poff" utilities to dial/hangup. These are contained in the "pppconfig" Debian package. You can use pppconfig to manually configure a ppp connection.

On the other hand, the "wvdial" utility (found in Debian package wvdial) is a pretty automatic command-line dialer.

Of course, most of us have risen to the 21st century and wish to use a GUI dialer. In my sister's case, I installed the "kppp" package for KDE. This package is really just a GUI wrapper for the pppconfig dialer mentioned above. Because of this, there were two issues that I ran into. The first is that pppconfig is not actually configured to allow kppp to function properly. The authorization is not set up correctly. If you try to dial in then the connection will always fail and complain about improper authorization.

Fortunately, the fix is to put the line "noauth" in the file /etc/ppp/peers/kppp-options (there is probably a line which reads "#noauth" - just uncomment it).

Second, when you do ACTUALLY get connected, there is a good chance that you will be connected at only 9600bps (very very very slow). This is because the modem port speed is set incorrectly (by default!) in kppp. In my case the port speed was set at some ridiculous number, like 476000bps. By decreasing this number to 56000bps (or the closest number) the connection was established at full speed.

The corresponding GUI dialer in GNOME is called "gnome-ppp". This is actually just a GUI wrapper for "wvdial" as mentioned above. I haven't bothered trying to get this to work (who still uses a modem anyway?).

This page has been visited   times since April 8, 2005