Linksys NSLU2 and Attitude Adjustment

Time is such a strange thing. I was cleaning up my pile of junk and suddenly saw my dusty Linksys NSLU2. I was wondering why it's sitting in the pile and whether OpenWrt would be available for it to make an easy print server. A quick search on the Internet revealed that I had written about OpenWrt myself 2.5 years ago.

I had completely forgotten that I had done this. I guess with Mom being sick and being overworked I had just lost track of things. Incidentally, this is why I haven't written much on my beloved blog. Since I'm in need of more print servers now, I decided to upgrade it to the current version of OpenWrt.

I booted up the NSLU2 and sure enough, it still has the exact same version of OpenWrt "Backfire" 10.03.1-RC5 that I installed back in 2011. The current release version, "Attitude Adjustment", was released in April 2013. So I downloaded an image for the NSLU2 and proceeded to upgrade it. The upgrade can only be performed using the Sercomm utility and not from the OpenWrt web interface, so I had to boot up my VMware image like before to perform the upgrade.

In Attitude Adjustment, the first USB printer device is /dev/usb/lp0, so the device name has to be edited. After that, everything works just fine.

Stupidly enough, after finishing the upgrade, I remembered why the NSLU2 wasn't being used. I actually let my users test it, but they didn't like it since it had to be manually powered on if power was lost. The NSLU2-Linux site actually has a page specifically for this issue. However, this may not be an issue any more today, as the new Epson printers that we've started using recently do not automatically turn themselves on when a print job is received. We used to use Canon printers that has this feature, but Canon stopped making small sized printers so we stopped buying them.

DD-WRT duplicate MAC address

Earlier this year I decided to upgrade my team of WRT160NL to the latest DD-WRT. The upgrade went fine, but afterwards I could only reach just one of the WRT160NL's. Upon closer inspection, I discovered that the MAC address on all of them were set to 00:11:22:33:44:55.

This would be perfectly fine for normal users who have just one such router in her LAN, but it didn't work for me since MAC addresses have to be unique in a LAN.

The nvram set command can be used to change the MAC address, but it only affects the MAC address displayed in the DD-WRT control panel, it doesn't actually change the MAC address. After some fiddling, I found that I need to use the ifconfig command, so the full command is:

ifconfig br0 down
ifconfig br0 hw ether 00:25:9C:CA:23:0D
ifconfig br0 up

The LAN MAC should be the same as the Wireless MAC, so that's what I used. The commands can be save as a startup command using the DD-WRT interface. And here's a screen capture of the new setting in effect.

Since I have more than 10 WRT160NL's, I had to go to each one to change the MAC address. This is a bug in DD-WRT, but since it only affects people with multiple routers, I think it may be a long time before it gets fixed, so my workaround will do for now.

Self-changing Wi-Fi password

I'm totally addicted to coffee, and whenever I see a new coffee shop, I would stop and try their coffee. These days, most coffee shops have free Wi-Fi, and sometimes, it's easy to drink one cup of coffee, and then steal their Wi-Fi permanently since most places don't have the knowledge to change their Wi-Fi password frequently. (Might as well not set a password if you never change the password!)

Presenting... automatic WPA2-PSK password changer for Tomato firmware. Put this little script into the Init script area (Administration -> Scripts -> Init). Now whenever the router reboots, a new password will be generated. You should also put this script either into a schedule so the password can change daily, or preferably, make a schedule to reboot the router daily.

As written the password is based on the current date. If you read the script below, you can see the password is based on a very simple formula: Year x Year x Month x Date, then use only the last eight digits. So if today is March 15, 2013, the password would be 82347605. You can vary the formula, for example, by using %U (week number) instead of %d to change the password weekly, or take out %d to change the password monthly. Just make sure the password is at least eight digits. I prepend the password with 00 in case the generated password is shorter than eight digits. It would be simple to make a spreadsheet with all possible future passwords, or even manually calculate the password.

The delay at the beginning of the scripts waits for the date to be retrieved by NTP. Note that if NTP time can not be retrieved, the Wi-Fi password will be the initial password, which is whatever you saved using the Basic -> Network configuration screen. My configuration is WPA2-PSK, other security types are untested. This script is tested on the ASUS WL500gP (v1 and v2) and the ASUS RT-N16.

You may have to change the nvram line depending on your Wi-Fi chipset if you have another Tomato supported router. The reason I set both wl and wl0 is that I needed both lines to support my notebook and my Android tablet. The wl line for my ThinkPad notebook, and the wl0 line for my Android tablet. If I don't have both lines, then only one device could connect.

Oh yeah, this is not a captive portal since there's no login screen for different users, but rather for changing the Wi-Fi password. As usual, no warranties.

#!/bin/sh
#www.ivoidwarranties.com
cat > /tmp/wifi.sh << EOL
#!/bin/sh
while [ \`date +%Y\` -lt 2010 ]
do
    sleep 10
done
YY=\`date +%Y\`
MM=\`date +%m\`
DD=\`date +%d\`
SUMD=\$((YY*YY*MM*DD))
WIFIPW=\$(echo "00"\$SUMD | tail -c 9)
nvram set wl_wpa_psk=\$WIFIPW
nvram set wl0_wpa_psk=\$WIFIPW
service net restart
EOL
chmod a+x /tmp/wifi.sh
/tmp/wifi.sh &

Will update this page again when I have time to test if this script also works on the DD-WRT firmware.

WRT54GL vs. H2O

This is the PCB of a good old Linksys WRT54GL that was completely submerged for approximately one month during the Great Thailand Flood of 2011. Oh, the router was actually placed on a desk, the water level was much much higher than that.

My domain and database servers were all safe since they were on the second floor, but I had to evacuate them (by boat) to another site, which I'll write in detail the next time. Computers that were on the ground floor were all dead, either directly by water or rusted by the humidity. Some I could actually salvage the hard drives or CPU's since the water level was lower, others were completely underwater.

Server evacuation

I'm stuck in the middle of the Great Thailand Flood of 2011. My entire factory was flooded, and I had to evacuate my server backups to a safe and dry place.

A few years ago, when I was writing policies for SOX compliance, there was a section about risk assessment and business continuity planning, and one of the issues was how to resume operations in case of fire or flood or other acts of God. Who would've thunk that after less than four years, everything I wrote has to be put into actual usage?

So, we were evacuated out to a nearby hotel with free Wi-Fi, and all the managers are connected to the free Wi-Fi, and then they need printing. So I went back to the flooded factory and took out (by boat) a trusty Linksys WRT160NL and a Canon inkjet printer. Previously I talked about using the WRT160NL to share USB printers, but this is slightly different since I don't actually have a LAN any more.

It turned out to be quite easy, I just joined the WRT160NL to the hotel's free Wi-Fi by using client bridge, then used Angry IP Scanner to find a free IP address outside of what I think is the normal DHCP range, and then I just pointed everyone's printer to the new IP address of the WRT160NL, and then we got printing.

While setting things up, I suddenly lost Wi-Fi connectivity, and I called the hotel's front desk to ask them to reset the Wi-Fi, and they told me the only Wi-Fi they have is down at the lobby, and it was working perfectly. I ended up having to find a maid on my floor to ask her if she has ever seen a little box with blinking lights, and she pointed me to a Linksys WAP54G. I simply power cycled the access point and all was fine again.

Linksys NSLU2 and OpenWrt

I have two Linksys NSLU2's that I bought three years ago, during the early days of this blog, to use as print servers. I chose to run the Unslung firmware and use CUPS as the print server. Unfortunately, after using them for a while, I discovered that NSLU2+CUPS was not stable enough for volume printing, and as I was able to get p910nd to run completely stable on a number of other wireless routers, so I had set the NSLU2's aside and switched to using wireless routers with USB ports. I loved the NSLU2's for what they're capable of, but a wireless router doubling as a print server and an access point is far more practical than a single purpose print server that needed a USB flash drive to work.

Recently I suddenly needed additional print servers to support our growing printing needs, and because the WRT160NL was discontinued, I decided to dust off the NSLU2's off and install OpenWrt on them. I thought that since OpenWrt has a much smaller footprint, and if I'm only going to install p910nd and the necessary USB support, it should fit the onboard memory.

I had to use VMware to run the Sercomm upgrade utility, since it doesn't work with Windows 7. When the NSLU2 is placed into recovery mode for flashing, it automatically takes an IP address of 192.168.0.1, so I had to change my VMware's IP address to the same subnet. I installed the latest version of OpenWrt "Backfire" which is 10.03.1-RC5 as of this writing.

After flashing, the NSLU2 automatically changed its IP address to 192.168.1.1. Because I did the flashing inside VMware, and I could configure the NSLU2 using a web browser in Windows 7, I actually had to change my Windows 7's IP address to connect to the NSLU2. I gave it a new IP address to go with my LAN, and plugged it into the LAN.

After that, I installed the p910nd and the USB support packages. These packages are needed: kmod-usb-core, kmod-usb-printer, kmod-usb-uhci, kmod-usb-ohci, kmod-usb2, p910nd, luci-app-p910nd. I was mostly concerned whether I would have enough memory, but as the image shows, no problems there.

After enabling p910nd and plugging in my USB printer, I could print right away without any problems, but after some testing, I found that once in a while I get a timeout when the print jobs are finishing up, which suggested that I needed to disable bi-directional signaling on the print server, and there's an option for that. One funny thing about OpenWrt on the NSLU2 is that it doesn't turn on the power LED light by default, but there's an option for that too.

So I'm happy with the NSLU2's again.

Upgrade pains

Sometimes I hate buying new hardware. It's one thing to experiment with new hardware, learning and breaking things in the process, but it's another thing when you've experimented enough and want to put the newly gained knowledge into production use, but only to find out shortly later that everything was in vain since that particular piece of hardware was discontinued.

This happened recently with the Linksys WRT160NL. I've wrote about the WRT160NL previously and mentioned that it was quickly turning into my favorite router. Coupled with recent versions of DD-WRT (17201 as of this writing) it's an extremely stable and capable wireless router. I have a number of them running as regular routers (ha!) as well as USB print servers and VPN servers. Unfortunately when I tried to buy more recently, the shops told me they're discontinued and want me to buy the Linksys Cisco E2000 or E3000 instead. I know the E2000 and E3000 are newer dual band routers with gigabit Ethernte ports, but I already have the WRT160NL running smoothly, buying an entirely different series would mean starting everything over again, and with a different chipset too. (Atheros vs. Broadcom.)

After some research, I found that the Cisco E2100L is the equivalent of the WRT160NL. Unfortunately, the E2100L isn't available locally. I called all my suppliers and they managed to find three WRT160NL's for me, so I bought them right away to keep them for future use. Over the past few months I've also recommended the WRT160NL to serveral friends, so I'm actually tempted to buy the E2000 to exchange with their WRT160NL's. I wish I still lived in the States as the WRT160NL is still available from Amazon.com. (Don't trust those reviews on Amazon.com.)

Still, it looks like it's time to break more things again.

Linksys WRT160NL and DD-WRT

A few years ago, I wrote about the Linksys WRT310N and DD-WRT. I no longer have that router since a friend decided to borrow it permanently, and I ended up selling it to him.

When my ASUS WL500gP died last year, I tried to buy another unit only to find it wasn't available locally any more. So I went looking for an alternative, and the Linksys WRT160NL was what I found. I've had one for a few months already, and recently I bought a few more as it's quickly turning into my favorite router.

WRT160NL has a 400 MHz CPU, 32 MB RAM, and 8 MB Flash. The It has a USB port ("Storage Link") for attaching USB storage devices. However, with DD-WRT, it can also be using for USB printing. The box has a penguin logo and it's just inviting me to put a third-party firmware on it.

I'm running the most recent DD-WRT (16214 as of this writing) on it. With this version, I can enable USB Printer Support from the web interface and it automatically works with my inkjet printer. With earlier versions I had to manually install p910nd to get printing to work. DD-WRT doesn't have a detailed changelog so I don't know when this happened, but I'm glad it works "out-of-the-box" now.

The DD-WRT router database currently shows version 14896 for download. This version seems to have wireless problems since I seem to lose wireless connectivity after a while. 16214 also seems to have fixed that problem.

While trying to figure out the wireless issues, I also followed the recommendations in this thread and set my TX Antenna to 1+2+3 and RX Antenna to 1+3 and Antenna Gain to 2, which seems to greatly increase my wireless stability and connectivity.

Oh, while I was playing with upgrading the different firmwares, the WRT160NL locked up completely. It would no longer finish booting and the power light just flashes. However, upon closer inspection, I discovered that the router wasn't actually "bricked", and I managed to recover it simply by using tftp to upload the linksys-to-ddwrt-firmware.bin to it. After it rebooted, then upload the actual wrt160nl-firmware.bin to it using the web interface.

Just to be sure that it wasn't pure luck that I recovered the router, I purposely crashed the router several more times, and each time I managed to recover it by using tftp.

The WRT160NL also works with Gargoyle, which I'll talk about next time.

Skype

7 million Skype users are online, and none of them are my friends. Skype has been down for almost 24 hours, and my phone has been ringing off the hook since this morning from desperate users who can't get in touch with their friends or customers. It's amazing for my users to realize how much they depend on technology when they're suddenly cut off from it.

I most definitely wouldn't want to be a member of Skype's IT team right now.

Internet over VPN

The kind of VPN that I know best is site-to-site VPN, which I've implemented a number of times using low-cost hardware. Recently though, I've became interested in using VPN tunnels to secure and encrypt my Internet connectivity, and also to access sites that I otherwise can't.

Before.

After.

Okay, the Wikileaks site I could always access by typing in the URL differently, but the other sites only work with an USA IP address.

Upgrading DD-WRT on the Linksys WRT310N

I let my boss borrow my WRT310N a few months ago. I didn't need it back since I had so many other routers to work with. By the time he gave it back, newer versions of DD-WRT had been released.

So I downloaded the latest beta release and tried to update it, but unfortunately, it seemed to brick the WRT310N. It did seem to respond to pings when booting, and I was able to tftp a firmware file into it using the reset button/tftp method, but no matter what I did, it wouldn't finish booting.

Finally I realized that to tftp a firmware file correctly, I had to hold down the reset button until the power light starts to blink, then release the reset button, then start the tftp transfer. It seemed funny that I'm only realizing this now after having done hundreds of firmware updates using the reset button/tftp method.

ALIX 2D3

Since I'm using pfSense now I decided to order some ALIX 2D3 to try out the multi-WAN functions. I also got some 2 GB CF cards since that's the smallest size I could find locally. Pretty sad that the smallest size at less than $10 a piece is faster than the ones I use with my DSLR, and I got those for like $200 each.

pfSense vs. P2P

It seems that changing the settings in m0n0wall didn't help a lot. The apartment manager called me up again and said instead of 10 users calling in per hour to complain, now 10 users calls in every two hours. I did more searching and found that spontaneous reboots under load on the ALIX appears to be a known issue. Plus m0n0wall's firewall states can't be changed even if I run it on a PC, so I finally decided to switch to pfSense.

pfSense started as a fork of m0n0wall, but for some reason it doesn't have the voucher system that m0n0wall has, so I didn't want to use it at first. But I found that pfSense's 2.0-ALPHA release does have the voucher system, so I decided to give that a try.

I installed pfSense on a PC with 2 GB RAM and gave it a state table size of 200,000; and on another ALIX board with 128 MB RAM, which I left the state table size at the default of 10,000. Unfortunately, during testing, I found that for the 2.0-ALPHA version, once I enable the captive portal, it says the gateway is offline and can't connect to the Internet. So I decided to go back to a more stable version (1.2.3-RC2), and let the apartment complex stay with the user login system for now, and go for the voucher system later. I also had to flash the ALIX with BIOS 0.99h to resolve a boot problem. All this took about an hour.

So I drove out 100 miles again to replace the two ALIX m0n0wall boxes with the PC and the ALIX pfSense.

And I remembered to take photos of the whole setup this time.

My two ALIX m0n0wall boxes stuck between the two Peplink load balancers. The white boxes on the top shelf are cheapo TP-Link ADSL modems.

This is hard to see since my notebook's screen made the rest of the image underexposed. There are now three ALIX boxes, the new one with pfSense installed. The PC on the bottom shelf is the one with pfSense installed.
Success! 24 hours of uptime! Previously, I couldn't even get 10 minutes of uptime with m0n0wall during peak usage. This screenshot came from the ALIX box as the platform type is nanobsd.
The ALIX 2c0's lowly AMD 433 MHz Geode LX700 CPU and 128 MB RAM coping with nearly 40 users on three 4 Mbps ADSL lines.

m0n0wall vs. P2P

I talked about using m0n0wall as a captive portal in an environment with an extremely large number of users earlier. From what I could see remotely at the load balancer, the system appeared to be running fine, since I could see all the WAN links being used. But the manager of the apartment complex called me up to tell me that users have been complaining that they get logged out of the captive portal, and they have to re-input their passwords. This often happens in the evenings when usage peaks.

I asked the manager if the users all called at the same time to complain about this, which could indicate that m0n0wall had crashed and rebooted, thus kicking all users out from the portal. The manager wasn't sure, but he said that he gets calls every single evening.

So I drove out 100 miles to see it again, in person.

It turns out that there still aren't that many users using the system, but those that are using, are hogging the bandwidth by running P2P software. I searched a bit and found that m0n0wall has a hard coded 30,000 connection limit (firewall states), which can't be changed unless the kernel is recompiled. It also appears that when the limit is reached, m0n0wall crashes. Hmm.

I could switch to pfSense and run it on a PC, which seems to not have any issues in this area since it has a configurable maximum states option based on the amount of RAM installed, but the current released is tagged ALPHA-ALPHA, which scares me a little bit. Or I could switch to some other system not based on m0n0wall, but I really like the captive portal, and the apartment complex people also intend to use the vouchers in m0n0wall.

So I changed the TCP idle timeout value, and gave minimum weight to P2P connections using the traffic shaper. I also remembered to set m0n0wall to allow remote access, so I don't have to drive out again if all I needed to do was look at users and change some settings.

But I forgot to take photos of the hardware setup again.

Large captive portal project

Earlier last month, a buddy referred me to a project he was handling. The site was way too far for him to travel to conveniently, and he was stuck with some other projects. So I decided to take a look.

The site was an apartment complex with six buildings and offers wireless Internet access to its occupants. They were having trouble with the existing system, so I accepted the project, and drove out 100 miles to look at it.


The old system: the apartment complex has six 4 Mbps ADSL lines. Every two buildings share two load balanced ADSL links. This sounds painfully slow and backwards, but 4 Mbps is the fastest we could get around here. (In fact, they had 2 Mbps ADSL until recently.)

They were using Edimax load balancers and Planet authentication gateways as the captive portal. The ADSL modems were also configured incorrectly as routers, giving three levels of NAT when it could be just two. Since there are six buildings with three sets of load balanced Internet links, it also means there are three sets of load balancers and gateways, and six modems. The real problem was that the Edimax and Planet often hang and required manual rebooting. Plus, the Edimax also oftens hangs in such a way that a cold reboot is necessary, erasing all configuration and requires manual reconfiguration. The Planet's captive portal also stops functioning randomly and would either allow the users to access the Internet without any authentication, or block Internet access completely. The biggest problem though, was that Internet access was so slow so even when the system was functioning, they were getting less and less users since the users were so sick of the slowness. And the reason they have three sets is not because they want to give more bandwidth to the users, but because originally when they had just one set, it would crash even faster.


The new system: replaced Edimax with Peplink. Replaced Planet with ALIX running m0n0wall. I recommended Peplink load balancers with 3 WAN connections, so now we can have just two sets of hardware, with three buildings sharing three load balanced ADSL links. I could have gone for a high-end Peplink with 7 WAN and combined everything into one set of hardware, but the initial investment would be much more expensive, and it's always nice to have a backup.

So I borrowed a Peplink 300 and a Peplink 380 (same as 300, plus VPN and in a rack form factor) from my friendly local Peplink dealer and deployed them. I reconfigured the ADSL modems as bridges, and set the Peplink into PPPoE mode. Unfortunately, the Peplink doesn't seem to have detailed QoS, so I configured m0n0wall to do the QoS by using the built-in Magic shaper wizard. m0n0wall was also configured as a captive portal with local users. We decided to user local users for now since the old system was based on users. We will implement a ticket selling system (called vouchers in m0n0wall) later if everything works out.


Oh, the ALIX boards I used were also the older ones I got from last year. They only have 128 MB of RAM, but seem to have no trouble handing a large number of captive portal user logins and traffic shaping.


According to the manager of the apartment complex, when the old system first went live a year ago, they could have up to 500 simultaneous users in the evenings. But because they've been having so much trouble with the system, the number had dwindled down to about 30.

We'll see how things work out.

(Doh! I forgot to take a photo after the Peplink and ALIX were installed. Will update again.)

DD-WRT httpd vulnerability

A critical flaw was discovered in DD-WRT's httpd service. It was also covered on Slashdot. I don't need really to upgrade since my two DD-WRT routers are completely stable, and they weren't even used as Internet routers.

Just to keep this upgrade exciting, I performed the upgrade over a VDSL link during a heavy thunderstorm. The micro one was a client bridge mode connected to the std one. There were no signal drops during the upgrade process.

WRT54GL:

WAP54G:
Before the firmware upgrade, I had a 151-day uptime on the WAP54G. Pretty incredible since the WAP54G is placed outdoors in an incredibly dusty and hot environment. As mentioned above, it's configured as a client bridge to wirelessly connect an RFID access reader to the rest of the LAN.

Gargoyle (access restrictions)

I first wrote about Gargoyle router management utility (beta 2) back in October last year. Since then, I've wanted to write more about it, but kept putting it off, plus the author (Eric) keeps releasing updates faster than I can write about them! Anyway, I'm now using an experimental beta 4.something, and it has a number of significant updates and bug fixes over beta 2.

The most significant new feature of the current Gargoyle beta is the access restrictions module. It is leaps and bounds above anything else out there because restrictions can be classified by IP, IP range, MAC address, port, protocol, or URL. The URL restriction can be processed by simple match, exact match, or regular expression using either the domain name part of the URL, or the full URL. Plus Gargoyle also has whitelisting (it's called Exceptions in the Garoyle UI). I'm especially happy about this feature because I threat^H^H^H^H^Hbegged Eric to have it implemented. It is essentially the same as restrictions, but works in reverse.

With the access restrictions and exceptions working hand in hand, you can create very complex access scenarios for the users. For example, you can block all downloading of .exe or .zip files to prevent users from downloading programs, but you can put in an exception for antivirus update sites, so users can still update their antivirus definitions. Another scenario is you could always allow employees/kids to access the company/school website, while other sites are allowed or blocked according to time of day. For me, my users often need to download files from government websites, which for some stupid reasons are always compressed self-extractable files. So for me, I block users from downloading all .exe files, but put in an exception for *.go.th sites.

The current beta of Gargoyle is also based on the latest OpenWrt beta (8.09RC2) so it can use the same packages and has the same hardware support as OpenWrt. Unfortunately, this version seem to use much more memory than previous versions, and when being used with the Linksys WRT54GL, I could easily crash the router by opening many connections at once, such as when running a bittorrent client, so I ended up buying an ASUS WL-500gP V2 to run Gargoyle with. The WL-500gP V2 has twice the flash and twice the memory of the WRT54GL, and Gargoyle is completely stable on it.

As of this writing, Gargoyle still has a number of minor bugs, but it's highly usable as it is. I'll write more about some of the other features next time.

In the screenshots below, I made a sample of the "block downloads, but allow antivirus updates" scenario I mentioned above.

Clicking on the edit button brings up a pop-up that allows further editing, in this example, .exe, .zip, and .rar are blocked by regular expressions.
However, all transfers from the avgate.net (Avira Antivir) and f-secure.com (F-Secure Antivirus) domains are allowed. This allows downloading of program files as well as antivirus definitions from those two sites.

Happy Y2.009K

Happy new year! Instead of vacationing, I spent the last few days helping a client switch over to a new ISP and the ISP hosted mail server. Unfortunately, they still refuse to switch over to Google Apps, so they have to deal with the ISP's poor mail service. Plus they're still using my Buffalo wireless router running Tomato, now with a slightly amazing 75 day of uptime. The last reboot happened when I updated the firmware. I even switched to the new ISP without having to reboot the router. After the new year, I'm gonna take it back so I can finally get to play with it myself.

I bought the Buffalo back in June and it's been at the client site since July. The Buffalo router is no longer available locally for some unknown reason, and the shop that I bought it from denies that they've ever carried it. (In fact, they've only ever had one piece, and I bought it.) So I really really want to try it out.

Ghost town vacation

I went on a holiday last weekend to Krabi and Phuket. Normally the beaches of Krabi and Phuket are filled with tourists, but since the PAD morons destroyed the country, the beaches and streest are mostly empty and many places are closed down.



When I was at Krabi, I stayed at a hotel right in the middle of downtown. In theory it sounds quite nice, but all the action is actually at the seaside at Ao Nang. Downtown is more like the middle of nowhere.

The surprising thing was the hotel has WRT54GL's at every floor, running Tomato with WDS enabled to provide free Internet service. I didn't see anyone else besides me using the service though. And how did I know they were running Tomato with WDS, and that I was the only user? Because they were all running with the default username and password.


Obligatory shot of James Bond Island.

These go to eleven

I've been looking at EnGenius products for a while, but I've not yet bought one for testing. EnGenius, also known as Senao in some parts of the world, is well known for making high powered long range access points, for both indoors and outdoors.

Fortunately, a friend got an ECB-3220 for one of his projects, and I borrowed it off him for testing. The ECB-3220 is a high-powered access point with 400mW RF output and bunch of other advanced features such as WDS, SNMP, virtual SSID, etc. Of course, all those advanced features can be had for free with DD-WRT. The only things I want with the EnGenius is the higher power output and PoE.


The body of the ECB-3220 is well constructed, and smaller than the standard Linksys WRT54GL. Which is to be expected, since the WRT54GL is half empty inside. The WRT54GL only remained that size to be compatible with older Linksys products and mounting frames.

Unfortunately, when I set it up for testing, it didn't seem to perform any better than the WRT54GL I have stacked below it. I kept getting the exact same signal strength level no matter what I tried. The ECB-3220 also has the same female RP-TNC antenna connector as the WRT54GL, so I also tried swapping antennas and changing orientation. I also have an ASUS WL-500gP (not pictured) which seems to give even better signal.

After some head scratching (and secretly glad that I didn't buy the more expensive ECB-3610S 600mW version for testing) I realized that the output power level options in the advanced wireless setup page has four values: High, Ultra High, Super, and Extreme. I had seen the options earlier but didn't change them because the default value is "High", and I thought it would default to the highest output value.

Once I set the output power levels to Extreme, everything worked as I had expected, I could get approximately three times the range of the WRT54GL when indoors. And when outdoors, I could go all the way up to nearly half a mile away. Testing was done with my ASUS EEE PC 701 with the Atheros wireless chipset.

Looks like I need to buy the ECB-3610S after all.