ISDN and Linux—Surfing at Warp Speed

This article presents a detailed tutorial on setting up an ISDN link to the Internet with Linux.
External ISDN Modems

A fair amount of confusion lies in this area. A typical question on comp.os.linux.networking is “Do I have to include ISDN support to operate my Bitsurfr ISDN modem?” Nope. An ISDN modem is a serial device that connects to the serial port on your PC, “dials” a phone number and translates ISDN data to RS-232 data. The system sees it as a regular modem. You can set up getty to answer incoming calls, and you can dial out with minicom or pppd. ISDN kernel support is neither required nor used. Note that the term “modem” does not really apply to an ISDN terminal adapter, because “modem” implies an analog device which an ISDN TA is not.

The Motorola Bitsurfr Pro is one such ISDN modem. I will discuss its connection to a Linux system in detail, because it has been around for quite some time and works well. It features a 115Kbps serial port and two POTS jacks. Newer ISDN modems may include a 230Kbps or higher serial port and compression (such as the Farallon Netmodem).

The test system for the Bitsurfr Pro was a Pentium 100 with 32MB of memory running Linux 2.0.28. The connection was provided by UUNET Canada and both a dedicated connection as well as a dial-up connection were tested. Both situations worked well with one or two B channels operating. The following procedure outlines setting up Linux to talk to the Bitsurfr Pro over the serial port and configuring pppd to use it.

  1. Connect the Bitsurfr Pro to the system and the ISDN line.

  2. Configure the serial port with setserial as required (e.g., setserial /dev/cua1 spd_vhi hup_notify). See the Serial HOW-TO for details.

  3. Now the fun part: configuring the Bitsurfr Pro. The Bitsurfr Pro requires a full VT100-compliant terminal emulator to use its local menu. During my testing, I have found only Seyon to work—Minicom did not work for me—run Seyon (i.e., seyon - modems/dev/cua1). Type AT to get the Bitsurfr's attention. Then type AT@MENU. The local menu will appear as shown in Figure 1.

  4. From the NET SWITCH menu, set up the switch type and the SPIDs (i.e., the ISDN phone line numbers). The directory numbers are required only if you intend to dial into the Bitsurfr. The Data SPID and Voice SPID2 should be made the same. Selecting “Port To Configure” selects which SPID to set up. Select “Reset Network Link” after the SPIDs are entered to start the Bitsurfr talking to the ISDN switch. If all goes well, the LS (link status) light will turn solid green. This can take as long as two minutes to occur.

  5. From the CALL SETUP menu, set the B Channel Speed to 64K unless ISDN in your area does not support 64K. Basically, if calls cannot be made, reduce this setting to 56K.

  6. From the PROTOCOLS menu, set “Rate Adaption Protocol” to PPPC.

  7. From the LOAD/SAVE menu, select “Save Total Active Profile” and save it to Profile 0 and Profile 1.

  8. Install pppd.

  9. pppd comes with a sample script in the scripts directory of its source tree. Copy ppp-off to the the /etc/ppp directory; ppp-off is used unchanged.

  10. Refer to Listing 1. Create the scripts as listed in the /etc/ppp directory. These are modified versions of the pppd ppp-on and ppp-on-dialer scripts. The ppp-on script runs pppd and the ppp-on-dialer dials the phone number. The ppp-on-dialer also controls the number of B channels the Bitsurfr uses. Most dial-up ISPs only permit one B channel usage. Check with your ISP for details. For two channels, the Bitsurfr must be told to use MPPP instead of PPP and must be given two phone numbers with the ATD command.

  11. Create an options file as in Listing 2. The debug option is useful for initial testing. Watch your syslog for messages from pppd. The name option is required to identify who you are in the chap-secrets file.

  12. Create the chap-secrets and pap-secrets files. The contents should be the same in most cases. Listing 3 shows an example. The chap and pap-secrets should have the same contents and should list every router on the remote end. In the example, most routers on UUNET's Alterdial POP in Toronto (Canada) are listed. To determine the remote router names, when connecting, monitor the syslog. The names are reported as part of the negotiations. This is an easy way to build a router list. Alternatively, call your ISP and ask for this information. ISDN routers do not issue normal login prompts and rely on chap or pap for authentication. Even if a login prompt were issued, it would not appear through the Bitsurfr's PPP support. All routers are listed twice in reverse order in case bi-directional CHAP or PAP is requested. (Cisco routers tend to default to two-way CHAP.) If you have a dedicated connection, you need list only the one router you are dialing in to; otherwise, you have to list all the routers you may hit in your dial-up connection.

  13. Go on-line by running the ppp-on script. If all goes well, you'll get connected. The DTE (data terminal equipment) light will flash while the Bitsurfr is dialing and glow solid green when the ISDN portion of the link is active. The total time from dialing to authentication is about 2 to 8 seconds depending on the load on the remote routers.

  14. Surf's up! Check the routing table to make sure a default route exists (i.e., run netstat -rn). If it does, ping something on the Internet. Your packets should be returned.

For a dial-up connection, you might want to go one step further and install diald, the Linux dialer daemon, to make your Internet connection automatic when Internet traffic is sensed.

There are a few problems that might occur in getting connected with Bitsurfr Pro. Incorrect SPIDs is the most common problem. Check with your telco for the correct format of the SPIDs. Secondly, a typo in the scripts will cause various weirdness. For example, an error in the phone number in the ppp-on-dialer can cause certain grief. Lastly, if the pap-secrets file is not set up correctly, it will cause authentication problems and failed connects. This error type will be noted in the syslog output from pppd when the debug option is enabled. Obviously, a lot of detail is missing from the above instructions; however, after some experimentation, things should start working. Check the PPP HOWTO for more details, as getting the Bitsurfr working is mostly a fight with pppd.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState