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.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- Designing Foils with XFLR5