On one of our projects, we’ve been using the Comtrol RocketModem IV for several years, for both modem communications and FAXing (with Hylafax). All of our RMIVs have been completely reliable and very easy to get working under Linux, particular Ubuntu/Debian which includes the rocket driver in-the-box.
Then we got a new card; it looks like the old cards; but according to the rocket driver it does not exist.
We initially suspected a bad card. We were unable to test with the floppy-image diagnostics on the Comtrol web site, because like most of the rest of the world we stopped ordering floppy drives in new machines several years ago. Comtrol support helpfully pointed us at a CD .ISO for the diagnostics, in here:
ftp://ftp.comtrol.com/contribs/rocketport/diagnostics/rocketmodem/
…without mentioning any reason why this information would not be on their support web site in 2008.
The diagnostics showed a 100% functional card. It finally dawned on me that I might need an updated driver for the current card; and this turned out to be true. The current RocketModem IV is not recognized at all by the rocket module in-the-box in Linux.
Getting it going was an adventure; the short version is that to get the current RocketModem IV to work on any vaguely current Linux kernel, you need to poke around the Comtrol web site and find the beta 3.08 driver, in here:
ftp://ftp.comtrol.com/beta/rmodem/drivers/u_pci/linux/
then do the usual apt-get of a build environment, make, sudo make install, /etc/init.d/rocket start.
Production Deployment
Of course the instructions above are for development / test usage; it is a very poor practice to do the above installation on production hardware, because it makes no accommodation for the inevitable stream of upgrades coming through the packaging mechanism, and because in most cases sysadmins prefer to not have a build environment on production hardware at all (ever).
I am no packaging / Debian expert, but I can see two workable paths to good production deployment for kernel modules like this:
1) Use checkinstall or similar mechanism to create a package which installs the binary modules; set things up so that the resulting package depends on the proper kernel package version. As new kernel packages appear, make new package versions to accommodate them, and likewise for each architecture (i386, amd64).
2) recast the raw source .tar file, as a source-deb package suitable for use with the Debian module-assistant mechanism.
I’d love to hear from any Debian/Ubuntu experts on the relative merits of these approaches.
Perhaps in a few years, things will settle back to the previous bliss of a working driver in the Linux “box”.
Update: I’ve posted a .deb for this here.