| My stuff: |
|---|
| .wgz.org: |
| .wgz.com: |
| Other stuff: |
| Publications: |
Some time ago, when I was living out of the reach of both DSL and DOCSIS, I had to use dialup internet access. I already had two modems, both Supra internals, one V.34 and the other V.90. The V.90 started acting oddly (periodically ceasing to respond until its power was cycled). Not wanting to fall back to V.34, I decided to buy a new, V.92 modem.
I decided on a USR Performance Pro, based on USR's reputation the last time I was shopping for a modem. Well, that was several years ago, and after ordering it, I read everyone's horror stories with the Performance Pro. I canceled the order and instead selected a Zoom 3049L (based on the Lucent/Agere Venus chipset -- there's a Conexant-based modem 3049C that I haven't tried). It occurred to me that I wanted an external modem this time, so I don't have to reboot to reset it. Zoom has impressed me a lot lately, with long warranties, good Linux support, and clear differentiation of controller-based and host-based modems. Yes, Virginia, the 3049L is controller-based (hint, it's external).
Now I have DSL, but I'm thinking about setting up something more complex than a 3-box digital answering machine for here, including some anti-telemarketing features and caller ID logging. I could use either of the Supras for the job, especially since the V.34 connects directly to the on-mobo Vibra in the system where it lives. On the other hand, the Zoom is a V.253 modem which supports call waiting and newer voice commands. This page is basically my scrapbook of efforts to set this up.
I downloaded 3049.exe from Zoom's website (it's easy to find in the support pages for the modem). This package includes a Modem-on-Hold applet for Windows and a flash upgrade utility to update the modem's firmware. Having only Linux boxes, I couldn't just run it and go. I installed WINE, but WINE doesn't get along well with InstallShield. I finally tracked down a windows utility called i6comp, which can extract files from InstallShield cabinet files (note that these .cab files are not the same as Microsoft's cabinet files). This page gives a quick example of how to use i6comp, which seems to run fine under WINE. I tracked down the applet (LtMoh.exe). It runs under WINE, and even docked into my KDE panel, but it couldn't communicate with my modem (had permissions correct, mapped COM port in WINE config) and segfaulted when I tried to change its settings. Oh well. Also in the InstallShield archive is Flash45.exe, along with two hex files. Excellent. With the serial port set correctly, I started Flash45.exe, which fired up, asked me for the flash file (ZOOMFD9E.hex), and started flashing the modem. So far, so good. I watched it load Flashldr.hex, then it said please wait, erasing flash. After a minute or so of that and no visible modem activity, I was pretty nervous. I left it running for a while to do other things. When I returned, it said it was done (phew). I tried communicating with the modem, and verified that the ROM was updated (ATI3 returns FD9E for the ROM checksum now).
So, it looks like the upgrade is possible under WINE if you use i6comp to extract the files instead of fighting with InstallShield. If you're at all worried about trashing your modem, though, you might just want to find a Windows box to do the update.
I've played around with mgetty and vgetty in the past, from configuring a Linux box as a PPP dialin server to a basic Caller ID logging setup. It has never been simple. The configuration strings are compiled into the binaries, and the auto-detection only recognizes a handful of modem chipsets. The two Supra internal modems I have had for years are pretty quickly detected as Rockwell (now Conexant) chipsets, and some supplemental init strings added to the configuration files enabled Caller ID collection. Basic voice functions seem to work pretty well on the Supra 288i Sp (SUP1440) (with 33.6 upgrade, became SUP1441. btw, this is an OEM modem made for Micron PCs), including multiple input/output locations (such as external handset, including handset off-hook detection), internal speaker/microphone (which patches directly to the motherboards onboard Vibra 16C sound chipset), and telephone line. This is one of those seemingly old-fashioned modems that automatically disables the handset while a data call is in progress. The newer Supra 56i Sp I bought around 1998 doesn't disconnect the handset, so if you pick it up you hear the carrier signals and can disrupt the connection with any noise the handset microphone picks up. It also doesn't support Class 2 faxing, so mgetty won't fax with it (Class 1 faxing is mostly software-driven, which worked ok on a non-multitasking OS that would allow the fax driver real-time priority. Class 2 faxing is mostly hardware driven, so it's much easier to support on multitasking systems.). This is common amongst K56-flex modems that had 1 meg flash ROMs. One meg turned out to be just enough space for either K56 or V.90 implementation, without room for Class 2 faxing. The two meg models that came later tend to allow simultaneous K56 and V.90 support, but I don't know about the faxing.
The Zoom seems to support Class 2 faxing, although I haven't tested it. So far, I've been experimenting with its more advanced V.253-supplied distinctive ring and call waiting support, and voice functions. It took me a long time to get vgetty to support voice functions on the 3049L. I finally made some progress with the help of the VOCP project. Following their directions, I downloaded the mgetty/vgetty source and applied a vocp-supplied patch that allows one to override mgetty's attempts to autodetect modem types. With this patch, I first tried to force vgetty to treat the Zoom as a V253modem, but I had trouble finding a well-supported compression mode. I did much better when I forced detection as Lucent. This convinces vgetty that the modem is a Lucent Venus V.90 USB modem, which is pretty close... probably won't support modem-on-hold, but that's not really as useful to me since I'm not using the modem for long-term internet connectivity. My interest is mostly voicemail and fax reception, maybe remote dialin to my home network.
With much experimentation, and running VOCP's little script to help choose the proper compression, I got voice playback and recording working properly. The only playback modes that worked properly, though, were I believe vm modes 2, 9, and 12. The only actual playback mechanism that seemed to work was the telephone line itself. In one of the modes, the modem went off-hook, but in all of them, the playback was audible on both the telephone line jack and the handset jack. I suspect the handset jack is just hardwired to the line jack, especially considering that this modem also does not disconnect the handset during data connections, and the fact that the modem reports no DLE-shielded code when the handset goes off-hook. So much for some handset-dependant stuff I wanted to do.