Using Intel 537EP 56K dialup modem in Ubuntu Linux 9.04 Jaunty 

During the initial installation of Ubuntu (disk partitioning and GRUB setup for dual boot with Windows), I studied carefully for two reasons: a) to avoid making a mistake and b) I "really wanted to understand" what I was doing. It was a great success. I did really understand what I was doing, and the result was flawless, so it made sense that I would take the same approach with the next step, configuring my dialup modem.

Unfortunately, there was quite a lot more to understand. The project took five days. A more reckless approach might have taken only a few hours with approximately the same result.

Reckless approach: "I have an Intel 537EP modem and an Intel 537EP driver. I'll install the driver and see if it works!"

My approach: "First, I will learn all about modems, study every available resource, learn about everything that can go wrong, read the man pages for each utility I might need to use, and assess the probability that my sub-version of the 537EP is exactly one of the ones supported by the 537EP driver. Then I will install the Intel 537EP driver and see if it works, because there is no other alternative."

It can be seen that the reckless approach offers potential time savings.

Where to start

I started at the best and obvious Ubuntu.com starting point for setting up a modem, followed all the links, including the one to the scanModem utility, ran it, discovered that it could not detect my modem, and further discovered that the subsystem of my 537EP PCI card (details at the bottom of this page) was not one of the ones listed as supported. It supported subsystems #100[7,8,A,0], and I had #1009. The difference might be in its FAX capabilities, but I'm not sure about that.

Now, even though there was some small doubt about whether the modem would work, the obvious next step would have been to install the driver and test it anyway, but I'll provide the following additional information because there are many other models of modems, and multiple variants of each model, so any of the information I gathered could have been necessary under different circumstances, and might be necessary for you. Windows XP can provide a lot of information about your modem, but it might not be obvious where to find it.

Gathering modem information

In Windows XP, I found detailed information about my PCI modem card at

start > Control Panel > Administrative Tools > Computer Management > Device Manager > [modem name] > Properties, all of the tabs and buttons, including Diagnostics > Query Modem.

Then I found even more useful information at

start > All Programs > Accessories > System Tools > System Information > Modem (and IRQs, and other sections)

The information gathered led me to the .inf driver file, containing lists of relevant AT commands, at

C:\WINNT\inf\oem7.inf

There is a log of the modem's recent activity, including the commands that Windows sent to it, at

C:\WINNT\ModemLog_Intel(R) 537EP Data Fax Modem.txt

I found information about how the modem connects to the internet (various settings) at:

start > Connect To > [right-click my ISP] > Properties > all tabs, all buttons for advanced information, etc.

Then I thought to do something I'd not seen anyone suggest on any of the web pages I'd read! I opened the computer's case and copied all relevant data off the modem's PCI card and chips.

Now, armed with everything I could ever want to know about my modem, I realized that my choices were: the 537EP driver, or... nothing. Guess I'd better try that driver.

To make a long story shorter:

With or without the driver installed, wvdialconf and GnomePPP could not detect the modem. From a suggestion found in forum posts, I tried creating a symlink from ttyS15 pointing to /dev/modem, but it didn't help, and the system removed the symlink anyway upon the next reboot. So I abandoned wvdial-dependent utilities, something I should have done sooner. Other utilities worked immediately.

picocom WAS able to communicate with the modem using these settings:

picocom -b115200 -fh -pn -d8 /dev/modem

When I entered ATZ (the Hayes reset command), the modem responded with OK. That's all I needed to know! I tried logging into my ISP with username and password, but it rejected my attempts, which was pretty much expected since a PAP login seems to require something more complicated, perhaps not easily done manually. I exited picocom with Ctrl+A followed by Ctrl+X.

Point-to-Point Protocol is known as PPP, and after the failures of GnomePPP and wvdial, I suspected my best hopes were in older and potentially more reliable command line tools. To find the PPP-related commands in Terminal, I typed:

man -k ppp

After running pppconfig and providing it the information it needed to configure the connection, I tried using pon to log in to my ISP. It worked the first time and every time since. Reliable! I disconnected with poff.

There are some additional possible settings in /etc/ppp/options that I haven't experimented with, but I think it might be possible to configure the settings I'm used to: drop the connection locally after 20 minutes of inactivity, and automatically reconnect if my ISP drops the connection.

On web pages, I kept encountering references to NetworkAdmin as another way to start my ISP connection, but couldn't find it anywhere. It turns out Ubuntu Jaunty doesn't install it by default. Once I'd installed it from Synaptic Package Manager, it was much easier to find, and after configuring and enabling the ppp0 connection there, that method of connecting to my ISP worked, too.

Once NetworkAdmin was set up, it became possible to use the Modem Monitor panel applet to connect, but it doesn't seem to show any useful status information, so I get the status information by running pppstatus in a Terminal; its display shows moment-to-moment changes in the ISP connection speed that I never knew were occurring when watching the status in Windows XP. It's even possible to guess about the load my ISP is handling at any given time, and whether there are network problems.

The only things that didn't work were the ones I tried initially: wvdial, wvdialconf, and GnomePPP.

Setting up a firewall

I didn't want to go online without a firewall, so getting something set up now became the highest priority. https://wiki.ubuntu.com/UbuntuFirewall/ describes ufw as an easy way to configure iptables. I got a chuckle about that when reading the ufw man page. If that's simple, then iptables itself must be scary enough to make a Halloween costume out of, though I'm not sure how you'd do that. Someday looking back I will probably see that it is not as bad as it looks, but at first glance it didn't seem quite simple enough for my immediate purposes.

I found Firestarter to be quite easy, and I especially like its continuously updated event log display, which is an assurance that it's correctly configured and working. At GRC ShieldsUp!, my system passed as Full Stealth once I enabled the Firestarter ICMP filtering option.

I also tried gufw briefly, but went back to Firestarter for its nice interface.

https://help.ubuntu.com/community/UFW has more information about firewalling.

Problems

The one problem I've encountered is that at least once, apparently, I think, when my ISP dropped the connection (which is fortunately rare), it froze my keyboard and mouse, and I had to restart the computer. Being a rare occurrence, this could take some time to sort out. The three things I currently consider possibilities:

1) IRQ18 is shared by the modem, an Intel Pro1000 Network Connection (which, however, has no network devices plugged into it), a USB controller, and a SATA controller. This seems like a heavy load, and the Ubuntu logs frequently show a complaint "Too much work for IRQ18". It's never been a problem in Windows, but that might be because Windows can't read the ext3 filesystem. It's never acknowledged the 2nd SATA drive's existence and never needs to access it, which would make associated IRQ conflicts unlikely. Something that might argue in favor of IRQ conflict in Ubuntu is that upon reboot there are sometimes several seconds of disk activity where nothing else happens, and then Windows XP boots even though Ubuntu should because it was the last-used OS. This could indicate that my boot drive (sda, holding Ubuntu) is in a leftover not-ready or misconfigured state from the failure at the time the boot loader needs to access it, and the disk activity is the system searching for alternate boot loaders on other drives/partitions. If IRQ conflict is the problem, the solution is probably to move the modem card to another PCI slot.

2) Nautilus was running when it happened, and I've experienced some other glitches with it. When Nautilus isn't running, my internet connection seems more stable, although it's difficult to think of a reason why that would be the case. However, I found other blog posts about Nautilus as a suspect in similar keyboard/mouse freezes, in situations where network connections weren't even involved, so I consider this a real possibility, and will try running without it for a while before moving the modem's PCI card around. Thus, it might have had nothing to do with the ISP hanging up, or maybe the system freeze caused the hang-up. The system was unattended when it happened.

3) Something else I haven't thought of.

The specifications of my 537EP PCI modem card

This "subsystem 1009" variation of the 537EP was preinstalled in the Gateway computer I bought in 2004, so I suspect it is very common. There is a specifications page for it at Intel. Other information:

Device Instance ID as reported in Windows XP Device Manager:

PCI\VEN_8086&DEV_1080&SUBSYS_10098086&REV_03\4&2E98101C&0&20F0

It is configured at: COM3

One sticker on the PCI card says: US: RIGM501B537EPU

The two chips in its chipset:

• Approx. 1" square, labeled: FA82537EP, Intel .. '02
• Approx. 1/4" x 3/4" chip: Si3017-KS

Identified in scanModem as:

PCI slot PCI ID    SubsystemID Name
-------- --------- ----------- --------------
03:04.0  8086:1080 8086:1009   Modem: Intel Corporation FA82537EP 56K V.92 Data/Fax Modem PCI

03:04.0 apparently means: PCI Slot 5 (PCI bus 3, device 4, function 0)

8086:1009 is not one of the subsystems that the scanModem documentation says is supported, and scanModem did not detect its chipset, but the driver does support this modem.

Questions and comments are welcome in the discussion forum.