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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide