Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

wireless bridge w/encryption?



R. Luoma wrote:
> I would like to set up a wireless bridge between
> two wired networks in my house.
> I am finding almost too much and not completely consistent
> flood of information in my web-searches.
> 
> "dd-wrt" has been mentioned several times on this list,
> though there seems to be a wide variety of hardware
> support (or not supported, depending on the whims of
> manufacturers).
> 
> I would appreciate:
>   - do people recommend "dd-wrt"?

The thing to understand about the 3rd party router firmware is that each
project falls into one of two groups: firmware that is derivative of the
manufacturer's firmware, and firmware that is built independently.

Projects like DD-WRT and Tomato[1] are derivative. The advantage is that
they make use of the proprietary drivers supplied by the chipset
manufacturers and thus tend to support a wider variety and more recent
hardware. They also tend to come with GUIs that cover typical
interactions and extend upon what the manufacturer's GUI could do. The
disadvantage is that they might be less flexible, less capable (for
advanced configurations), and less stable.

1. http://www.polarcloud.com/tomato

Projects like OpenWRT[2] provide an independently built Linux
distribution using open source drivers. It tends to take longer before
they support any given hardware, and for some hardware that can't easily
be reverse engineered, it will never be supported. How things work in
OpenWRT is less of a "black box" compared to the derivative firmwares.
It used to not come with a GUI, but I believe one or more GUIs are now
available.

2. http://openwrt.org/

I used to use DD-WRT, but had stability issues. I only tried it on a
couple of versions of the classic Linksys WRT54G, so I can't say whether
it was a hardware or software issue. When I upgraded to ASUS RT-N16
hardware, I took a look at what 3rd party firmware was trending more
favorably, and went with Tomato, specifically the variation that
supports USB[3]. I've ran across a few bugs, but generally stability has
been good.

3. http://tomatousb.org/

One standout feature of Tomato compared to DD-WRT is that it properly
handles version upgrades without requiring you to reset the non-volatile
memory of the router. With DD-WRT they recommend that after each upgrade
you reset everything and then reconfigure the router.

I haven't had occasion to use OpenWRT, but I'd tend to recommend one of
the derivative firmwares first, unless what you need to do is complex
and beyond their ability.

Linux Journal has published a series of articles on building a
transparent firewall with OpenWRT[4], which can give you a flavor of
what its like to work with OpenWRT.

4. http://www.linuxjournal.com/article/10816

Keep in mind that supposedly none of the Linux-based firmwares are
really high performance[see also 4] or "enterprise" quality. Though for
almost the same price you can achieve that, using something like the
RouterStation Pro[5] and the FreeBSD based pfSense[6]. (Anyone with
first hand experience with these? I'm considering building a
router/firewall with them.)

5. http://www.ubnt.com/
6. http://www.pfsense.org/


>   - anything else regarding wireless bridges that I should know?

I haven't had occasion to setup a wireless bridge, but I've ran across
many mentions of people setting them up on the DD-WRT and OpenWRT
forums. At times there have been bugs that have prevented this from
working. But it is a pretty common need.

My recommendation would be to do some data mining specifically in the
forums for Tomato and DD-WRT and go with whichever people seem to be
reporting the most success with at the moment.


>   - what encryption options are available?

You should be able to use WPA/AES, which is the preferred WiFi
encryption option. Someone else mentioned a VPN, which you can use too,
though it is probably overkill if the other end of the LAN is your
private LAN behind a firewall. My personal preference is to use
encrypted protocols wherever possible, even on a LAN. Either way, you'll
want to still use WPA/AES, otherwise you are vulnerable to ARP
spoofing[7] and other attack vectors, even if you use a VPN.

7. http://en.wikipedia.org/wiki/ARP_spoofing


>   - recommendations on what hardware is currently available

If you don't need 802.11N, then you have hundreds of choices.

If you do, I like the ASUS RT-N16 hardware, though it uses a chipset
that doesn't come with open source drivers, and thus will likely never
be supported by OpenWRT.

Hardware selection is something the 3rd party firmware projects could do
a better job at. The question constantly comes up on their forums, but
it can be difficult extrapolate a top pick from the discussion. They
really need a rating database, where you can plug-in some criteria, like
needing 802.11n, and then get results sorted by price, performance,
success, etc.


>   - if so, how do I avoid "bricking"?

The issue of bricking tends to scare off a lot of people. I tend to
think it is a non-issue, as long as you follow the instructions on how
to load the firmware, and you're using hardware that the project has
supported for a while, so you aren't playing guinea pig.

With modern hardware the process of upgrading to third party firmware is
relatively simple. Typically you use the router's supplied GUI and
upload the firmware with a browser. (Oddly, I've ran into problems doing
this with Firefox on Linux several times and had to use Chrome.) At
worse you might need to upgrade to an intermediary firmware that's
smaller or otherwise better designed to spoof the manufacturer's
firmware better, such that the OEM firmware accepts it as valid, then
upgrade to your intended firmware. There after you can use the 3rd party
firmware's GUI to do upgrades.

If the computer you intend to use to perform the upgrade is connected to
your LAN via WiFi, resist the temptation to just plug the target router
into your LAN somewhere and send it the firmware over your WiFi link.
The safer option is to plug the target router directly into the LAN port
of your computer. (You might need to play around with the 'route'
command to retain your WiFi LAN connectivity.)

The newer routers also are better designed to guard against bricking,
like performing integrity checks on uploaded firmware before overwriting
the old firmware, and like boot loaders that don't get overwritten on
upgrades.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org