OpenWrt Forum Archive

Topic: OpenWRT to FreeWave (900 MHz) Bridging

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have an interesting situation in which I need to bridge two networks though about 1000 feet of trees.

I already have two 900 MHz data transceivers made by FreeWave (model DGR-115: Technical Specifications) that interface via an RS232 connector.  These are rated for 25-60 miles (line of site of course) at 115.6 kbps, 1 mW.  I will be testing these devices this week to see if they can punch through the trees.

Now, the trick is to interface two WRT-boxes with these devices.  I've read the posts detailing redirecting TCP/IP activity to a COM port so it appears that it can be done but on one end, I will need to bridge LAN (WiFi disabled) to 900 MHz, and on the other end 900 MHz to LAN and (encrypted) WiFi.

So, here are the questions:
1) Do I simply need to build RS232 adaptors to the serial port on the WRT's board and load the ser2net packages?
2) If so, what type of routing do I need to setup and are they simply iptables rules or something else?
3) It would be nice to increase the bitrate over the connection by compressing data on the fly, can OpenWRT do this?
4) If all of this is possible, which WRT-box would be best suited?  Whatever device is chosen will need to be purchasable though a store (no Ebay) since my project is for a research institution.

Thank you in advance!

(Last edited by bkloppenborg on 6 Jun 2008, 03:16)

Okay, I read a little more about the 900 MHz radios and found out that when they are connected they function as a null modem cable.  I also tested the radios and they appear to connect through the trees so it appears we have a viable option.

So, it appears that all I need to do is make a virtual interface on each OpenWRT box and then bridge the network using the slattach command that comes as part of the net-tools package.  I found a quick guide that will probably work for OpenWRT, although it is written for Debain.  I'll let you know how it turns out.

As it turns out, this task was simpler than I expected.  I got this to work with one of my two WRTSL54GS boxes and my laptop computer (Ubuntu Linux box).

First, I installed the necessary modules to get USB working, after that, I installed the usb-serial modules including the module for my pl2303 adapter:

ipkg install kmod-usb-serial kmod-usb-serial-pl2303

After that, I grabbed stty:

cd /bin
tar zxf stty.tgz
rm stty.tgz
chmod 775 stty
ln -s /lib/  /lib/

An uncompressed version of stty is available at in case the site in the above code is offline.  Since the power in the remote location is unreliable, the box may get turned off from time to time so I created a hotplug script for the serial adapter to automatically change the baud rate from 9600 kbaud to a faster value:

Contents of /etc/hotplug.d/usb/02-USB_Serial:


# A script to increase the baud rate of a USB to Serial adapter on hotplug.

# Look for serial devices and then increase the baud rate:        

if [ "$ACTION" = "add" ]
        # search for last usb to serial assignment in syslog (/var/log/syslog.log or

        DEV=`logread | grep -i ttyUSB | grep -io "usb/tts/[0-9]" | tail -n 1`

        if [ "$DEV" != "" ]
                `stty -F /dev/$DEV $BAUD -crtscts`


So, after that I had to make a two different ppp connections; one for the dial-in server and the dial-in client.  The server keeps a ppp connection open, just waiting for a call (silent) and will resume listening after the connection is broken (persist):

Contents of /etc/ppp/peers/900MhzLink:

/dev/usb/tts/0 115200

where is the local IP and is the remote IP.  So, then it is just making a startup script to get the server up and running:

Contents of /etc/init.d/S98SerialPPP

pppd call 900MhzLink

Finally, we modify the routing rules (contents of /etc/firewall.user):

iptables -A FORWARD -i ppp0 -o eth1 -j ACCEPT

You could, of course, change eth1 back to $WAN so that everything is automatically configured but I hard-coded it since this is, at the moment, still in testing.

As for the client, I initiate the connection on the dial-in client manually so I type in:

pppd crtscts /dev/usb/tts/0 115200

to get the ppp connection up and running.  After that, I change the routing tables with:

route add default gw

There isn't much of a reason why this couldn't be done via an if-up script associated with the ppp0 interface but since I'm still testing, this is good enough for now.  This should be enough to get anyone else most-of-the-way to a working bridge system anyway.

Edit: as it turns out, my client bought two ASUS WL-500GP v2 units that are supported only under (the trunk version of) Kamikaze so the remainder of my setup and configuration will be listed in that forum after everything is working.

(Last edited by bkloppenborg on 1 Jul 2008, 06:00)

The discussion might have continued from here.