ISDN and Linux—Surfing at Warp Speed
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.
Connect the Bitsurfr Pro to the system and the ISDN line.
Configure the serial port with setserial as required (e.g., setserial /dev/cua1 spd_vhi hup_notify). See the Serial HOW-TO for details.
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.
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.
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.
From the PROTOCOLS menu, set “Rate Adaption Protocol” to PPPC.
From the LOAD/SAVE menu, select “Save Total Active Profile” and save it to Profile 0 and Profile 1.
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.
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.
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.
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.
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.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Home Automation with Raspberry Pi
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- Huge Package Overhaul for Debian and Ubuntu
- Purism Librem 13 Review
- Look Mom! I'm on the Internet!