UrlBlogGrey

The OpenWRT firmware uses the dnsmasq program as a caching name-server and DHCP server. It's has a small memory and filesystem footprint, and contains a feature-set perfect for most residential networks. I wanted to continue using dnsmasq as DHCP server for both networks. This meant configuring dnsmasq to issue IPs on two networks, or run two separate dnsmasq processes configured to issue IPs on a specific network.

First, I consulted the web-site for dnsmasq. The Man page indicated some options of interest:

-a, --listen-address=

"Listen on the given IP address(es)."

"Setting this option also enables multiple instances of dnsmasq which provide DHCP service to run in the same machine."

"Use the specified file to store DHCP lease information."

• Copy the initialization script (S50dnsmasq) for dnsmasq so that two processes at boot. I created two scripts (S50dnsmasq-lan1, S50dnsmasq-lan2).

  root@OpenWrt:/etc/init.d# ls   
  S05nvram         S50dnsmasq-lan1  S50inadyn        rcS
  S10boot          S50dnsmasq-lan2  S50telnet
  S40network       S50dropbear      S60cron
  S45firewall      S50httpd         S99done

• I then modified the scripts to cause each dnsmasq process to listen on a different network interface (customize "iface" variable). I also added options to the "args" variable to allow multiple dnsmasq processes and listen on a specific interface.

  root@OpenWrt:/etc/init.d# more S50dnsmasq-lan1
  #!/bin/sh
  
  # The following is to automatically configure the DHCP settings
  # based on nvram settings. Feel free to replace all this crap
  # with a simple "dnsmasq" and manage everything via the
  # /etc/dnsmasq.conf config file
  
  # DHCP interface (lan, wan, wifi -- any ifup *)
  iface=lan1
  ifname=$(nvram get ${iface}_ifname)
  
  udhcpc -n -q -R -s /bin/true -i $ifname >&- || {
    # no existing DHCP server?
  
    # calculate settings
    ipaddr=$(nvram get ${iface}_ipaddr)
    netmask=$(nvram get ${iface}_netmask)
    start=$(nvram get dhcp_start)
    start=$((network+${start:-100}))
    num=$(nvram get dhcp_num)
    num=$((start+${num:-150}))
    eval $(ipcalc $ipaddr $netmask $start $num)
    leases=/tmp/leases-${iface}
    
    # and pass the args via the commandline
    # (because trying to edit the config from here is crazy)
    args="--listen-address=$ipaddr --bind-interfaces --dhcp-leasefile=$leases -F $START,$END,$NETMASK,12h"
  }
  
  # ignore requests from wan interface
  wanproto=$(nvram get wan_proto)
  [ -z "$wanproto" -o "$wanproto" = "none" ] || args="${args} -I $(nvram get wan_ifname)"

• Make sure that the scripts are executable (chmod +x S50dnsmasq-lan1).
• Restart the router and check the processes:

  root@OpenWrt:/etc/init.d# ps -eax | grep dnsmasq
    444 nobody      416 S   dnsmasq --listen-address=192.168.1.1 --bind-interface
    460 nobody      396 S   dnsmasq --listen-address=192.168.2.1 --bind-interface

That's it! You should now have two DHCP & DNS servers running on separate network interfaces.

Posted by Scott at 11:11 AM | Permalink

I hope to be getting a Nintendo DS handheld soon, which has got me totally excited! The DS is equipped with an 802.11B (11 Mbps) network adapter, and is capable of using WEP encryption when connecting to an access point. It's great that the DS can use wifi, but it sucks that it uses such outdated standards. Our home network currently uses 802.11G (54 Mbps) and the more-robust WPA encryption standard.

WPA and WEP are mutually exclusive, as they ought to be. WEP has been proven breakable through methods like packet-injection. A network is only as strong as its weakest link, which in this case is WEP. So, placing the WEP and WPA clients on separate networks is required in order to preserve the security of WPA clients. I'd rather not compromise the security of the other devices (laptops, printer server, Linux box) for the sake of a Nintendo handheld.

So, I need to create two separate wireless networks: one using WEP, and the other using WPA. This requires me to purchase an additional wireless access point. I've been using a Linksys WRT54GS for the last 2.5 years, and would like to continue using it if possible. I run the Open Source OpenWRT firmware on my Linksys WRT54GS and have been very pleased with it's configurability, performance, and security. The current WRT54GS models do not support using firmware like OpenWRT, so I'll need to purchase a WRT54GL ("L" is for Linux).

The network currently looks like this:

                                                 |- WiFi clients (WPA)

Internet (WAN) --- (WAN Port) Linksys WRT54GS ---|

                                                 |- Ethernet switch

After adding the WRT54GL, the network will look like:

                                                 |- 802.11b (WEP)
Internet (WAN) --- (WAN Port) Linksys WRT54GL ---|                                                   |- 802.11G (WPA)  
                                                 |- Ethernet switch -- (WAN Port) Linksys WRT54GS ---|
                                                                                                     |- (Ethernet switch)

I must either disable the bridge between the 802.11B Virtual LAN (VLAN) and the Ethernet switch on WRT54GL, or I must keep the Network Address Translation (NAT) firewall active on the WRT54GS. This is to ensure that clients on the 802.11B network cannot access any hosts on the secure 802.11G network. I think that disabling the bridge will yield the best performance since it eliminates the need to double-NAT Internet traffic heading to the secure 802.11G network, yet keep the secure and non-secure networks separate.

I'll try to post a follow-up with the configuration changes once I put the network into action.

Posted by Scott at 5:30 PM | Permalink

I've been really satisfied with the performance, features, and reliability of the OpenWRT firmware for the Linksys WRT54GS wireless gateway router. The WRT54GS that I purchased two years ago is equipped with 32 MB of flash RAM, most of which goes unused with the stock OpenWRT installation. So, I figured it would be a interesting exercise to install the Snort Intrusion Detection System (IDS) software on the WRT54GS to report potential network attacks or anomalies.

Snort is the most popular open-source IDS software available, and features an actively-updated list of signatures and rules that can be used to identify attack-patterns in network traffic. The primary concern with installing an IDS on the WRT54GS is the scarcity of computational and storage resources. It has got a fairly weak processor in comparison to the desktop systems we're familiar with, and the memory used for storage and running processes is extremely limited. Linksys equipped the early WRT54GS models with 32 MB of flash RAM, but later reduced it to 16 MB in what I assume was an attempt at reducing manufacturing costs. So, those with an older model are actually better off in most cases. Here's an indication of resource utilization with Snort running:

I installed the Snort utility using the OpenWRT Admin Console, pointing the installer to the "Nico Testing" repository (http://nthill.free.fr/openwrt/ipkg/testing). Once Snort was installed, I just edited the Snort configuration file (/etc/snort/snort.conf) and was snort'ing in no time. I found the article on Linux.com to be very helpful, as it inspired me to start hte project and offered guidance along the way.

I also configured Snort to log messages to a Linux PC I've got running on the LAN. Resources are so scarce on the Linksys WRT54GS that it's not practical to store log messages locally. Instead, I currently have Snort configured to send messages to the router's syslog daemon which redirect the messages to a Linux machine on the LAN. The Linux machine then commits the messages to it's local log. Next, I'd like to use the MySQL relational database to store the log messages instead of the flat syslog text file. There are several log-visualization tools (i.e. ACID) that can show log data in a more meaningful format, such as in a web browser.

Posted by Scott at 6:36 PM | Permalink

I have a Linksys WRT54GS wireless access point at the center of my home network. I've installed the OpenWRT firmware on the access point to take advantage of some capabilities not present in the off-the-shelf firmware (see my post "OpenWRT on our Linksys WRT54GS"). Since the access point is powered "on" all the time and it has direct access to the WAN (Internet) interface of the network, it seems like an ideal place to run a program capable of maintaining my dynamic DNS entry.

There is a program called 'inadyn' that can publish an IP address to the Dynamic DNS Service. I needed to install 'inadyn' on my OpenWRT access point. This was done by editing the /etc/ipkg.conf file on the OpenWRT system to contain an entry for the URL of the package list that includes inadyn (http://www.syslinx.org/wrt54g/openwrt). Here's some output from my secure shell session:

root@OpenWrt:/etc# more ipkg.conf
src whiterussian http://downloads.openwrt.org/whiterussian/packages
src non-free http://downloads.openwrt.org/whiterussian/packages/non-free
src phil http://www.syslinx.org/wrt54g/openwrt
dest root /
dest ram /tmp

Then, I installed the inadyn program using the web interface provided with OpenWRT. Next, I created a configuration file that is used by inadyn to determine how it should connect to the Dynamic DNS Service and update your entry. Again, here's some shell output indicating the contents of my configuration file (located in /etc/inadyn.conf):

root@OpenWrt:~# more /etc/inadyn.conf
--username foo --password bar --update_period 60000 --alias foo.dyn-o-saur.com

Lastly, I created an initialization script that will be run when the router restarts. Since the inadyn program will run continuously, this initialization script should keep us in business indefinitely. I named my script S50inadyn, which indicates the order (once the network facilities are active) in which the script should be run during start-up. Here's some shell output indicating the contents of the file:

root@OpenWrt:/etc# cd /etc/init.d/
root@OpenWrt:/etc/init.d# ls
S05nvram     S41wpa       S50dropbear  S50telnet    rcS
S10boot      S45firewall  S50httpd     S60cron
S40network   S50dnsmasq   S50inadyn    S99done
root@OpenWrt:/etc/init.d# more S50inadyn
#!/bin/sh
/usr/bin/inadyn --input_file /etc/inadyn.conf &

You should be able to restart the router and see that the inadyn program is running. Simply login to the router and get a list of processes:

root@OpenWrt:/etc/init.d# ps -ea | grep inadyn
  513 root        332 S   /usr/bin/inadyn --input_file /etc/inadyn.conf

Now you can access the WAN port of your access point using a convenient DNS name. You'll probably want to configure some port-forwarding rules in order to access computers within your network. However, I recommend using port-mapping in order to lessen the obviousness of your open ports.

Posted by Scott at 9:59 AM | Permalink

I installed an Open Source firmware called OpenWRT on our Linksys WRT54GS wireless access point about 2 months ago. My main reason for doing so was that it allows me to perform port mapping rather than just port forwarding. This allows me to map WAN service ports to different LAN service ports. This a neat trick to reduce the likelihood of a network attack since services are exposed on the WAN/Internet adapter on non-standard ports.

OpenWRT has demonstrated itself to be highly configurable and reliable. I also like the ability to run a caching DNS service. And, I can assign static IP addresses to my LAN computers and publish their computer names through the DNS service. It's much easier to remember the host-name 'tivo' than '192.168.1.2'.

OpenWRT also provides the ability to install numerous modules on the system, and is limited only by the access points small amount of physical memory. I have version 1.0 of the WRT54GS, which yields 32 MB of RAM - plenty for what I require of the system. I highly recommend using the OpenWRT firmware if you've got a Linksys WRT54GS or other supported device. My access point was purchased in Spring 2004, and I'm amazed that I can still rely on it to provide me fast, secure access without an upgrade in over 2 years. Perhaps I should expect more of my other electronic devices!

Here's a screenshot of what the web-based administration tool looks like:

Posted by Scott at 9:58 PM | Permalink

It has been a few weeks since I installed the Netgear WGPS606 wireless printserver on our home network. It has been working great, and I have no complaints to speak of. This is significant considering that we run a pretty diverse network - one Fedora Core 5 machine, two Macs, and a Windows XP system.

I recently installed the OpenWRT firmware on our Linksys WRT54GS wireless access point (AP). The Netgear WGPS606 connects to the AP in order to interact with the other systems on our network. The stock Linksys firmware doesn't make much of a distinction between WPA and WPA2 when accessed through the adminstration interface. However, the OpenWRT admin interface does make a clear distinction between the two, including the encryption algorithms they use. According to the WPA and WPA2 specifications, their primary differrence is that WPA2 uses the more cryptographically-robust (and computationally-expensive) AES algorithm used by the U.S. government, while WPA uses a relatively weak TKIP/RC4 algorithm that is much faster (hence it runs well on cheap hardware, like the WGPS606). I don't mean to knock RC4, as it is perfectly acceptable for my home network, though AES is the current standard for high-grade encryption. So, I'd rather use WPA2 if given the choice.

I tried using just WPA2 with AES on the AP but was unable to get the Netgear WGPS606 to join the network. Only when I enabled WPA with TKIP/RC4 did the WGPS606 join.

My conclusion is that the Netgear WGPS606 supports WPA with the TKIP/RC4 encryption algorithm, but does not support the newer and more robust WPA2 standard. Hopefully this can be remedied by a firmware upgrade for the WGPS606 in the near future.

Posted by Scott at 5:34 PM | Permalink

I just finished reading an interesting write-up on an accidental Denial-of-Service (DoS) attack launched against network-time servers at the University of Wisconsin by consumer network equipment made by Netgear. More than 700,000 Netgear broadband routers made around 2003 had hard-coded entries for Network Time Protocol (NTP) servers to access for time updates. At the top of the list of servers to use was a system at UWisc. Even worse, if the Netgear routers were unable to contact the UWisc servers, they would repeatedly send requests every second. This created a flood of traffic against UWisc that paralyzed their public Internet infrastructure.

Netgear created patches for the offending routers which updated the NTP client implementation and the list of NTP servers to use. However, there are always going to be unpatched consumer systems in use that will continue to access the UWisc server. The patches must be applied by the consumer, which implies that the customer is knowledgable about product defects in the first place (certainly not the majority of consumers). The only thing that will ultimately solve the problem is product obsolescence. The offending Netgear routers were made in 2003 and featured 802.11b technology, which is becoming less prevalent due to the entry of much-faster 802.11g wireless technology. As consumers upgrade their home-networks to use 802.11g, they will likely discard their old equipment such as the Netgear routers responsible for this DoS attack. I actually owned one of the Netgear products involved in the attack (MR814) until I upgraded to 802.11g and gave the router to my parents for use as SPI firewall on their broadband connection.

It's all too easy for product designers to compromise long-term thinking when dealing with bleeding-edge technology. Yes, the product will ultimately be part of a "dumpster-upgrade", but the damage that consumer technologies are capable of when networked en-masse must be respected.

Posted by Scott at 9:53 AM | Permalink

I recently purchased a Netgear WGPS606 ("606") wireless print server for use on our home network. I've long been looking for a print server that would permit us to hide our huge HP Deskjet 5150 printer in the closet. It is far too expensive in terms of how much space it takes up in relation to the frequency of use.

What made the 606 so attractive is that it is wireless (802.11g), supports WPA encryption, and can be used with Windows, Mac, and Linux systems. The only other wireless print server I've seen that supports WPA is from Linksys, but it is incompatible with Mac OS X. Since two of my computers are Macs, the Netgear won hands-down.

Installation of the print server was fairly easy, although someone less technically adept would encounter a lot of difficulty. First, my Linksys access point issues all clients IP addresses in the 192.168.1.x subnet; however, the 606 comes configured with a statically-assigned IP in the 192.168.0.x subnet. I had to manually specify the IP address on my desktop computer to place it in the 192.168.0.x subnet so that I could access the web-based configuration utility on the 606. Once I was in, I quickly configured the 606 to join my wireless network. I actually had to change my network configuration to use WPA2 with TKIP+AES, whereas I previously used strictly AES (more cryptographically robust than TKIP). Also, the 65-character key for my access point needed to be shortened to 63 characters for the 606. That was a bit annoying.

Once done configuring the 606 for network connectivity, I moved on to configuring the printer. I learned that the 606 print server can be used as a standard UNIX "Line Printer Daemon" (LPD). This is cool. The two printer ports have queues names L1 and L2, respectively. I installed the CUPS print drivers on my Macs and was printing immediately. The printing output looks great, and the queues look the same as if the printer were connected directly to my computer.

Another feature I plan to take advantage of soon is the Ethernet-bridging feature. The 606 has 4 switched-Ethernet ports on the back which can be used to connect 10-BaseT Ethernet systems to the wireless network. In my case, I have a PC running Linux that I would like to stash in the closet along with the printer. The PC would have complete network connectivity, all while being less of an eye-sore.

Posted by Scott at 5:30 PM | Permalink

We've been using a D-Link 802.11G wireless network adapter with our Series 2 Tivo for the last 6 months with little difficulty. However, Tivo doesn't seem to understand that the Wired Equivalence Privacy (WEP) has a weak authentication mechanism and has long been replaced by the Wi-Fi Protected Access (WPA) standard. We'd like to use WPA, but are stuck using WEP until Tivo makes the move.

Yesterday, I became fed up with the wireless support in Tivo and purchased a USB Ethernet adapter to provide the Tivo with a wired connection to our broadband router. This will provide the Tivo with a secure wired connection, and allow us to upgrade the security on the wireless network to use WPA 2. The network adapter I ordered is the Netgear FA120. It has received good reviews on Amazon and was reasonably priced ($25).

The other solution I was considering was to buy another wireless router that could be configured to use a low grade of security (WEP), and use our existing wireless router to provide a high grade of security (WPA) while connected to a switch port on the low-security router. This was too complex and expensive to implement. It would have meant spending at least $40 on the access point. Also, an additional access point represents one more system to secure and configure. Purchasing a wired Ethernet adapter was a much simpler and secure solution.

Posted by Scott at 8:20 AM | Permalink

We've been using the Wired-Equivalency Protocol (WEP) encryption standard to secure our home's wireless network since we discovered that Tivo doesn't support the more secure Wi-Fi Protected Access (WPA) encryption standard. Unfortunately, it's not possible to run some devices on a wireless network with WEP, and some with WPA; rather, it's all-or-nothing. So, we've downgraded the security of all our devices for the sake of Tivo. Our Powerbook and Mac Mini connect to the network using WEP, when they could be using WPA instead.

Recently, I heard on a podcast program called Security Now! that it's advisable to chain wireless access points (APs) in scenarios like mine. The layout would have the DSL/Cable modem connected to a low-security access point, and a high-security access point connected to the low-security AP on one of it's ethernet ports. Here's a basic diagram:

                      [ethernet]                    [ethernet]

[Internet] ---> Modem -----------> Low-Security AP -----------> High-Security AP

                                     |                            |

                                     | low-security clients       | high-security clients

The primary difference in this architecture is the presence of an additional AP that allows the creation of secure and non-secure network segments. Both segments are completed isolated from eachother. This might create problems if the high-security clients wanted to access resources on the low-security client segment, but allowing this would be invalidate the whole purpose of creating these two separate network segments. The low-security segment effectively becomes a Demarcation Zone (DMZ) that is distrusted as a policy. Yes, this is a good thing.

So, I'm thinking about buying another Linksys WRT54G, or WRT54GS, to handle the low-security clients. Having a low-security segment also makes it easier for friends or guests visiting your home to use the broadband connection without going through the hassle of configuring their client to use the high-security AP. Seems like a good idea!

Posted by Scott at 9:12 AM | Permalink

We are enjoying the benefits of wireless broadband after toning & probing our apartment phone line and getting rid of my improvised wiring setup. I've long pondered the merits of sharing wireless. For a couple of weeks we were enjoying an unprotected access point adjacent to our residence. It offered reasonable speed and reception, and was free. We really appreciated it till it vanished. Hmm...

I considered opening up my access point (AP) when our broadband was activated. My AP (Linksys WRT54GS) offers Wireless Isolation, which prevents wireless users from snooping on the traffic of other users or accessing other machines on the wireless network. This would provide a reasonably safe way of allowing others to use my wireless network. But would they abuse the bandwidth? It's hard to say.

It'll be great when individuals and communities open their networks to create a single, redundant network accessible from outside the boundaries of the home or workplace. But, just as in the days of medieval fiefdoms, open doors represent an open invitation to hostility. It'll take a change in the attitudes of users (sense of community and trust), and improved security features (doors with locks but open roads and gates) to get us there.

Posted by Scott at 9:41 AM | Permalink

Yesterday I had the idea of using my Linksys WRT54GS wireless access point as a bridge to a neighboring wireless network. I knew that that capability didn't exist in the WRT54GS out of the box, but that there are various projects on the Internet touting aftermarket firmware capable of such a task. The most popular being Satori, from Sveasoft. I was able to download the firmware from LinksysInfo.com and install in a matter of minutes.

1) Unzip the Satori distribution to obtain the .bin firmware image
2) Login to the access point through the Linksys web interface
3) Choose to upgrade the firmware with the Satori firmware image
4) Once the image is installed, reset the Linksys access point by holding the 'reset' button for 15-20 seconds
5) Login to the access point to confirm successful installation of the new firmware
6) If currently running in 'AP' (Access Point) wireless mode, change it to 'client' to act as a client to the primary network. Specify the SSID of the primary network in the SSID text box.
7) Disable the DHCP server and assign a static IP (192.168.1.10, something currently not used) to the router.

Now, the router should be capable of bridging the ethernet switch to the neighboring wireless network.

Posted by Scott at 12:40 PM | Permalink