Connecting SSC via Wireless Modem
Recently, SSC needed more room and rented another office. The remote office needed a connectivity solution to link it to the original office's LAN. Several options were available to us:
Frame relay (56k, T1...)Advantage: high speedDisadvantage: high cost of line and hardware
ISDNAdvantage: relatively high speedDisadvantage: potentially expensive hardware, long wait for installation
28.8k serialAdvantage: cheap hardware, readily availableDisadvantage: low speed
Wireless networkingsimilar to ISDN
Guerrilla Ethernet (run our own coax down the street) Advantage: 1.555-> 2.5 Mbits fastDisadvantage: street sweepers
We explored each possibility, and decided that outside of the probably illegal guerrilla Ethernet, wireless modems would be the most fun to install and use. We contacted various vendors for wireless products and found Freewave had the highest-speed wireless modems available. Freewave sent us a pair of modems to test at the office.
The Freewave modems we received were small and easy to configure. The manual stated they could potentially be used at a range of 20 miles, line-of-sight. We would soon see if that was a true statement.
Freewave wireless modems act as a null-modem cable, and unlike regular modems, do not need dialing. The modems look for other modems on their frequency and link to them. Wireless modems can link point-to-point, i.e., two modems, or multiple modems can be connected to a single modem that acts as a hub. Point-to-point, the modems are configured as a master and a slave. One calls the other and a link is established. The number they call is an internal, firmware encoded number.
The firmware of the Freewave modem is accessed by pressing a dimple on the front plate of the unit, which puts the modem into configure mode. Connecting to the serial device with minicom or xc at 38400 bps enables you to access the firmware menu. You then have the options to configure the speed the unit will use to talk with other modems, the numbers of the other Freewaves to call, and the behavior of the unit with the other modems—as a slave or a master.
Since we wanted point-to-point usage, the number was set to the number of the second modem, and the speed was set to 115200 bps.
Exiting the firmware puts the unit back in communication mode. It took several configuration tries to get each Freewave configured with the right speed as master and slave. Finally, the status lights on the units showed us a link, and flashes of packets could periodically be seen. We noticed that at 115200 bps, with the modems 20 feet apart, we weren't communicating well. Characters could not be sent either way even though a link was definitely established. Our communication test initially consisted of using minicom to send “Hello? Is it working? See this?” back and forth between modems.
We dropped the speed back to 9600 and established a reliable, clean link. We also discovered that sometimes the firmware on one of the modems would suddenly configure itself to be the master instead of the slave and talk at odd baud rates like 230400 bps.
After an hour or two of playing with the firmware, we were able to get a reliable 115200 bps connection at 20 feet. Now it was time to test a link between the two offices. The new office is south of the old at a distance of approximately 1500 feet with a large nursing home and several houses in between (read: not line-of-sight). After spending 2 or 3 hours beating on bad serial ports and slow 16450 UART-equipped hardware, we finally built a system with 16550As and were able to test the modem. The modem was placed in the window, just in case an extra wall might make a difference. After a bit more banging on the firmware, we finally established a connection with the office at 115200. We had link speed and reliability with a couple of transfers of the Linux kernel back and forth, and we also met with some problems. Occasionally the link would freeze, which meant resetting the modem, which in turn sometimes caused a glitch in the firmware. Other times it would transfer flawlessly at 7-8Kbytes/sec, a respectable performance. All in all, we decided that this performance, though quite good, was not robust enough to act as a LAN bridge to the remote office. Therefore, we packed up the modems and sent them back to Freewave.
I believe that with line-of-sight or at least minimally-blocked usage these modems could yield quality results. They're the fastest wireless modems we found—others we researched had maximum rates of 9600 bps. The initial cost was high, at about $1500 per unit, but given the costs of similar performance hardware, such as ISDN routers, DSU/CSUs and such, the overall cost was actually low, since there are no line charges. With improved reception (boosters were very costly) these units would have served their purpose quite well. Without it we decided to use an ISDN instead.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Fancy Tricks for Changing Numeric Base||May 29, 2016|
|Working with Command Arguments||May 28, 2016|
|Secure Desktops with Qubes: Installation||May 28, 2016|
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
- Tips for Optimizing Linux Memory Usage
- Working with Command Arguments
- Secure Desktops with Qubes: Introduction
- Secure Desktops with Qubes: Installation
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- CentOS 6.8 Released
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Fancy Tricks for Changing Numeric Base
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide