The most recent version of these essays can be found at http://linuxmafia.com/~rick/faq/.

Rick's Rants

("That's what you get for swimming in the shallow end of the gene pool.")

-Virus-    -Linux Tire-Kicking-    -Proprietary Warez-    -Hardware-    -Netiquette-    -Crybaby-    -Modems-    -MacLinux-    -Miscellany-   

Economy of expression is a good thing. So, rather than have to repeat myself continually, I'm posting my top rants here, for ready reference. Many of you (readers) will be visiting today because I pointedly referred you to the "#"-tagged URL of some particular item, below.

Modem Department

• "I'm having problems with my internal PC modem. Will you help me?"

  Yes: Your internal modem, if roasted and ground sufficiently finely, will make surprisingly strong espresso. That would be my advice.

  If you're happy with your internal modem, terrific! (But then, why are we talking?) If not, the most common symptom is "My OS doesn't let the modem dial out", and my first-level reply is likely to be "Well, what do your modem's (activity) LEDs say, when you try?" Of course, internal modems have no such LEDs. Which is my point.

  Some xylocephalic folk interpret that dictum as meaning that I dislike internal modems because they lack LEDs. Wrong, cellulose-brain! It's intended as a humourous way of pointing at the last straw in a whole series of woes that make those internal modems — the ones that are proving uncooperative — a pain to diagnose.

  A large part of diagnosis is breaking down large problems into series of smaller ones, and solving them systematically. Consider an external modem that won't dial: You've tried typing "AT" (modem, come to attention) in a modem app such as minicom for Linux, but the modem isn't replying "OK", as it should. That command goes first to the selected serial port. (You've verified that minicom's using the correct port.) So, you think, OK, is the port bad? You test this by connecting a serial mouse to the port, and seeing if mouse software (such as gpm) works. If the mouse software fails, then the port is non-functional, or is disabled in hardware, or has no driver in the OS. Fix the hardware and/or furnish the driver.

  If it's not the port, is it the serial cable? Try a different cable, and maybe check that it's not "null-modem" (that pin 2 connects to pin 2). If it's not the cable (that's defective), maybe it's the modem: Borrow a different one and try it, and try yours on someone else's machine. Do the Send Data and Receive Data LEDs blink when you type "OK"? (Did you remember to type "ATE1", to enable modem-command echo?)

  Follow the above approach with an external modem and, the moment you get an "OK" or activity LEDs blinking, you've won: You know that you've broken through, and can control the modem. All that remains is details, such as using correct dial-out scripts.

  By contrast, if an internal modem doesn't work fully from the start, most means of diagnosis are unavailable thereafter: The serial port and modem on the card are hard-wired to one another, and so cannot be tested separately. The lack of activity lights (LEDs) means that, even if you've done everything right except enable modem-command echo, you'll never notice the resulting modem-traffic activity telling you you're 98% done — because there are no lights to tell you so.

  Worse, most older internal modems are configured as Plug and Play ISA (16-bit card) devices. (Newer ones are PCI, about which see the winmodem section, below.) ISA PnP has never worked well, and in pre-2.4 kernel versions requires manual configuration in Linux (using the isapnptools package). The modem's serial port, in current machines, ends up being the box's third or fourth serial port, and consequently has a non-standardised and unpredictable IRQ assignment.

  (If stuck with an internal modem, you may therefore find it beneficial to disable one or more unused serial ports in the motherboard's BIOS Setup screens, so that the internal modem's serial port can become the box's first or second serial port, which are standardised. However, note that you may still need to set up isapnptools, too. Alternatively, with some ISA modems, either jumpers or a bundled configuration utility will allow you to disable the card's PnP mode and instead specify the on-board serial port's hardware resources explicitly, thereby eliminating the need for isapnptools and making the port visible to Linux's serial driver without further effort. Doing so would be an excellent idea.)

  Problems beyond the scope of this discussion include the usual poor construction quality in internal modems and their ability to fry motherboard circuitry when they fail (which happened to me), plus their extra heat load inside an (often as not) cramped and already-hot PC case, and their inability to be moved easily to other PCs (or at all to non-PC computers), and their inability to be reset without hard-booting the PC. Those don't hinder me in trying to help you diagnose operational problems. However, they, like all the others, go away magically if you use even a cheap external modem, instead.

  So, when I ask you to return when you can describe what the LEDs say, that's why.

  Note: Somehow, a large number of of the above text's readers fail to heed what it says in paragraph 3: I nowhere claimed that internal modems can't work to the satisfaction of many. The point was to advise those having problems with their internal modems, about why such modems are difficult to diagnose and fix (and give specific tips about how to fix them anyway). Please do not send a testimonial for your Fooware internal whatsit: It's irrelevant to the point.

• "I bought an external modem, and it was a piece of crud!

  I'm sorry to hear that, but I never said being external was a sufficient condition for quality, just a necessary one. Contrary to the opinion of many, getting a name brand isn't a good heuristic, either. Hayes/Cardinal, Supra (Diamond Multimedia), and Zoom Telephonics, for example, all make undistinguished products that would never get my hardware dollar. Most if not all of these products that fall short share the handicap of cheap, poor-quality chipsets from Conexant (formerly Rockwell), which I would always avoid.

  Modem chipsets: US Robotics/Texas Instruments good, Conexant/Rockwell/Agere/Lucent/AT&T/Motorola bad. I simply would not buy a modem based on the latter, period. Please see also my Hayes Optima review, which pretty accurately predicted (in early 1997) the present state of the modem market.

  For decades and still as of this date (September 2015), the clear winner in modems has been the 3Com (formerly US Robotics) Courier V.Everything External. However, don't just take my word for it: Please see also John Navas's Best of the Best page.

  (2015 note: In all fairness, Navas stopped maintaining his Modem FAQ in 2008, because, let's face it, few people care about modems, any more.)

  As with any modem, a Courier doesn't really shine until it's configured. One does this with minicom (or some other terminal app) and an open copy of the modem's "AT"-command reference manual. Do not trust to the manufacturer's default settings, which are often sub-optimal. (This holds true for any manufacturer.) Properly configured, a Courier is unexcelled (e.g., in my experience as a six-year operator of a networked BBS) at getting optimal communication from a huge variety of equipment at the other end, even under adverse line conditions.

  Please note that I did not say "3Com [US Robotics] Sportster". The Sportster series has been of extremely variable quality, and at best have been a notch below the Couriers. What, you object to the Courier's price (US $ 250)? Then, you're not serious about getting quality merchandise that will give good service over a very extended usage life (with probably lower cost per year, in consequence). Go ahead; buy cheap. Just don't blame me when you get cheap-product results.

• I bought an internal [/external] modem, am sure I've done everything right, and it still doesn't work!

  You may have a winmodem. This term originates from the name of a specific, really bad U.S. Robotics internal-modem product line, but is used generically to refer to an entire class of cut-rate modems — also known as "soft modems", "software modems", "host-based modems", "host-controlled modems", "HSF modems", "HSP modems" (host signal processor), "controllerless modems", and (as a common example) Conexant (formerly Rockwell) HCF-series modems (using RPI = Rockwell Protocol Interface) — that omit some traditional modem circuitry and substitute MS-Windows "engine" software.

  If you do have a winmodem, it will work inside MS-Windows 3.x and 9x/ME, only. Period. You have lost. (Some generally deficient exceptions are noted below.)

  Give up, and donate your so-called modem to someone you don't like. Better yet, take it back for a refund.

  Details: By definition, a winmodem is one that requires MS-Windows "engine" software to function, because it lacks otherwise-required circuitry. Some, the "controllerless" variety, are MS-Windows-dependent because they lack a controller chip (a ROM) where error correction, data compression, and modulation standards (such as V.90) would ordinarily be implemented. Thus, it is now possible, through the miracle of Conexant (formerly Rockwell) and Agere Systems (formerly Lucent, formerly AT&T) "technology", to manufacture an external modem so brain-dead that, outside MS-Windows, it's a paperweight!

  The other variety are internal units whose integrated serial ports lack the customary UART chip (universal asynchronous receiver-transmitter), and may also lack the aforementioned controller (ROM) chip.

  How to tell: By definition, if a modem works outside MS-Windows, it isn't a winmodem. So, the acid test is to try exactly that: If you have a Win9x/ME partition on your hard drive, or have a bootable MS-DOS floppy disk, you can do this with a simple DOS-type modem application such as Telix. If using Win9x/ME, you must start it in DOS only. (Do not use a DOS session inside MS-Windows.) Boot your machine, and wait until you see "Starting Windows" on-screen. Immediately hit the F8 key. From the "Boot Menu" then displayed, pick "Safe Mode, Command Prompt Only". Fire up Telix or equivalent.

  At this point, you will have to configure the DOS telecom program to address the correct serial port — which presupposes that you know what it is. If the port is what DOS calls "COM1" (called ttyS0 in Linux) or "COM2" (which is recommended, and is ttyS1 in Linux), supply that information. If it's "COM3" or above, you must know the specific hardware IRQ and I/O base address assignments of the modem's serial port (because the IRQ isn't standardised). For this reason among others, it is a good idea if possible to ensure that your modem is on "COM1" or "COM2" (e.g., by disabling unused serial ports in the motherboard's BIOS Setup routine in the case of internal modems). With external modems, this obstacle, like many others, doesn't exist.

  Once your telecom program is addressing the correct port, type "ATE1" followed by the Enter key. If the modem responds "OK" on-screen, then you have proved conclusively that your modem is not a winmodem. If it does not, then you either have not carried one of the above steps correctly, or it is a winmodem.

  As a quick rule of thumb, the original packaging for winmodems may include one or more of the phrases "Requires Windows", "RPI", or "RPI+". However, the earlier test (the "acid test") is definitive, while this rule of thumb isn't.

  Theoretically, programmers could write substitute "engine" software for non-MS-Windows operating systems. This would have to be done separately for each OS and for each modem-type crippled in some distinctive way. Further, it would entail reverse-engineering each such design's programming interface, without cooperation from manufacturers who classify this as proprietary information. In any event, programmers seem highly unlikely to bother, because they find it far easier to buy real modems, instead.)

  This FAQ item used to list all known exception to the general rule of PCI-type internals being winmodems, but the list became too complex. Your best bet is to check your make/model and chipset information against Rob Clark's databases (1, 2) and linmodems.org.

  Some quixotic souls are finding ways to run sundry winmodem chipsets under Linux:

  • PC-TEL "HSP" (PCI) chips: proprietary binary driver
  • Agere/Lucent/AT&T "LT" aka Apollo (ISA) and Mars/Venus (PCI) chips: often thrown in as a cheapo, no-name OEM part by IBM, HP, Dell, Gateway, Compaq, and others: proprietary binary driver
  • Agere/Lucent/AT&T "LT" aka Apollo (ISA) and Mars/Venus (PCI) chips: open-source driver (but not functional, yet). Please note that the Agere/Lucent AMR chipset is not compatible and not supported.
  • Motorola SM56 chips: proprietary binary driver and kludged fix for some recent kernels
  • Intel Modem Silicon Operation (formerly Ambient Technology, formerly a division of Cirrus Logic) "HaM" MD563X chipsets (with MD5628 DSP) only: proprietary binary driver
  • Ambient Technology (later bought by Intel, and formerly a division of Cirrus Logic) CL-MD5620DT chips: open-source driver
  • IBM "MWave" ACP chips: open-source driver
  • Conexant (Rockwell) HSF and HCF chips: proprietary binary drivers — which are now not only proprietary but also cost money if you want one that's not deliberately crippled; the last free-of-charge one is here.
  • Conexant (Rockwell) HSF chips (HCF not supported), kinda-sorta works without error-correction or data-compression if you disable RPI functions: proprietary binary driver
  • ESS ES56T-PI, ES56-PI, and ES56V-PI (PCI) TeleDrive chipsets (with ES2898S DSP chip): proprietary binary driver
  • ESS ES56V-I, ES56-I and ES56T-I (ISA) TeleDrive chipsets (with ES2890S DSP chip): proprietary binary driver
  • SmartLink (formerly ST Micro) SmartPCI56/561/562/563, SmartUSB56, and HAMR5600 chipsets: proprietary binary driver

  Do "lspci -vv" and "lspci -n", while logged in as the root user, to list all PCI devices in hopes of identifying your PCI winmodem chipset, if that's what you have. ("cat /proc/pci" is also useful.) For PnP ISA devices, try "/sbin/pnpdump". Then, check Rob Clark's databases (1, 2) and linmodems.org. to see if you're in luck or not.

  Binary-only drivers are very bad news, and should be shunned. (They're typically buggy for lack of peer review, poorly maintained, not portable to newer or different CPU architectures, prone to breakage with routine kernel or other system upgrades, etc.) Besides, you're still trying to make a silk purse from a sow's ear. Pursue this path, if you absolutely must justify your US $30 mistake, but You Were Warned.

  What about USB-bus modems? Alas, almost all have turned out to be winmodems. Again, your best bet is to consult Rob Clark's databases (1, 2) and linmodems.org.

Last modified: 2024-10-10

rick@linuxmafia.com

Copyright (C) 1995-2024 by Rick Moen. Verbatim copying, distribution, and display of this entire article (page) are permitted in any medium, provided this notice is preserved. Alternatively, you may create derivative works of any sort for any purpose, provided your versions contain no attribution to me, and that you assert your own authorship (and not mine) in every practical medium.

---

Top of page