Tuesday, September 14, 2010

Adding a DynDNS client to OpenWRT's LuCI

OpenWRT is terrific. The more I play with it, the more I like it. Even though I used to be a UNIX administrator (and a good-enough one, I think), I prefer using the LuCI interface as much as I can, keeping the CLI for repetitive tasks or debugging. LuCI is completely modular and lets you add packages depending on your specific needs. This is a good thing; it removes clutter from the interface and saves some precious space on your flash.

As an example, the following is a quick procedure that shows you how to add a DynDNS client functionality in LuCI.

Log into LuCI and switch to Administration mode.

Go into Overview -> LuCI Components.

In the Available Packages panel, install the luci-app-ddns package.


A Dynamic DNS menu entry will appear automagically.

Inside this menu, you can then add your DynDNS settings as usual. It might take a while before OpenWRT updates your status; be patient.

O.

Friday, September 3, 2010

The RNX-GX4, a well-priced Broadcom router

Remember how I blogged about OpenWRT and Broadcom routers a few months ago? Turns out I've been looking for a new router and I found one which did what I wanted at a good price:
I introduce you to Rosewill's RNX-GX4. This is a rebranded Netcore NW618, a chinese router which is not available this side of the Pacific. What makes this router special is that it is tested with, and officially supports, DD-WRT at a reasonable price -- I got mine on sale, at almost a quarter of the price of a WRT54GL. It has the same quantity of RAM and flash as the WRT54GL, but a faster CPU. It's not a straight WRT54GL clone; there are some differences such as a serial flash chip which isn't as common as parallel flash. But the patches have been submitted to the various distributions, and up until now, it has been working well.

What further sets it apart from many other low-cost routers is how Rosewill openly brags about how it runs a BCM5354KFBG 240MHz CPU in the technical specs online, and even on the back of the retail box. When you see things like this, you know it is made for geeks. I also appreciate that the antennas can be removed. I don't intend to use the wireless radio on this device, so I'll put them out of the way.

I've started playing with it tonight. My intention is to replace my m0n0wall PC with a RNX-GX4 running OpenWRT. While I like m0n0wall very much, running it on a generic PC takes some real estate and electricity, and using a smaller devices would be a better fit. I've investigated purchasing an Alix board, to keep running M0n0wall, but there are many, many times the price of the RNX-GX4 so I decided against using one.

O.

Building a low-power FreeNAS Server: Part 2

Part 2 of my series will be a shopping list of the materials I've picked to build by FreeNAS server.

Everything starts with the motherboard. I was looking for a low-power Mini-ITX board that had a built-in gigabit ethernet controller and I've decided to pick an Intel D510MO. This is a desktop board based on the Atom processor which is cheap and low power. There were third-party Atom boards that were maybe 10-15$ less than the Intel-branded one, but some reviewers complained on excessive heat and I didn't want to have heat problems. I was initially looking into the VIA C7 platform but it can't beat the Atom in terms of performance. I still don't know if the intel BIOS built on this board can work on a serial console. That would be surprising, but I will keep you posted.

I purchased two 1Tb Seagate 7200 RPM SATA disks -- nothing special here, except that 7200RPM was an imported factor for me. I want these disks to be as fast as possible when I'm copying large amounts of data.

For the case, I picked a cheap MicroATX one. Why MicroATX? Because Mini-ITX cases are expensive, and usually can't fit more than one hard disk. I selected a R102-P from Rosewill which happened to be 20$ on Newegg. That case is not only cheap, but it can hold 4 hard disks (which doesn't seem too common on MicroATX cases) and the front is very well ventilated with a lot of air holes right in front of the disks.

The case doesn't come with a power supply. And I didn't want to; since I was looking to be the most power-efficient possible, I picked a 80-Plus 250W power supply from Sparkle. 250W for an ATX form factor is also not that common, but I was really looking into getting what I need and not more -- an idling 500W PS consumes more power and one rated at 250W.

The last thing I bought is a gizmo made by Koutech - an adapter that converts a 10 pin USB header into a standard USB plug. Using this, I can put FreeNAS on a small USB key, and plug that key directly on the motherboard inside the case -- no dangling key outside the box. The motherboard doesn't have an IDE header, so I couldn't use a more common IDE to CF card converter. We'll see how this goes.

That's it for now. I'm currently in the process of having all this shipped to me and I will soon see how things work out.

Monday, August 30, 2010

Building a low-power FreeNAS Server: Part 1

I've been looking into having a small file server in my home, to store my photographs and iTunes library. The most important aspects of that file server are, in order:
  • Low power requirements: It is on 24/7 and I want don't want to consume too much power
  • RAID-1: I want my data to be protected in case the hard disk crashes
  • Low cost
  • Good performance
  • Expandability: Nice features such as a bittorrent client are a plus, I want to be able to experiment with DLNA in the future, so the "hackability" factor is important.
There were two contenders here that met most requirements: DLink's DNS-323 and Synology's DS-210j (Buffalo has some too but they are hard to find online). They each had a drawback: the DNS-323 is reported by many to be subpar in terms of performance, while the DS-210j is expensive.

So I decided to build my own NAS instead. It will most probably be based on FreeNAS, assuming it is hackable enough to my taste. The overall price is below the DS-210j, and I expect performance to be up to my expectations. Low power being paramount, I had to hand pick all the components and my next posts will detail what I've chosen, and how I'll be building it. I'll try to put some nice pictures.

O.

Thursday, August 19, 2010

wuauclt.exe and svchost.exe taking memory on XP

Update 2010-08-21: The thread here indicates that Microsoft is investigating this as a priority 1 issue.

Normally I don't post PC and Windows-related stuff but there are not many recent posts on this August 2010 issue, so here it is.

I support my own PCs and those used by the extended family. For a few days a staggering issue has been happening. When configuring a Windows XP PC to use Microsoft Update (rather than the good old Windows update), svchost.exe and wuauclt.exe take so much memory that a low-memory PC (512Mb) will start swapping enough to freeze the whole system. I saw this happening on SP2 and SP3.

Yes, 512Mb is not a lot, but before calling me stupid, note that 512Mb used to be the standard configuration a few years ago for many low-end systems and it is officially supported by XP. That bug makes any low-memory PC unusable.

You should note that installing Microsoft Security Essentials switches any PC silently from WU to MU. That's how I introduced the problem and noticed it the first time on a laptop. I was about to reinstall it but found out that there have been some user reports here and here. Microsoft has not released a patch yet but I am sure many corporate users have stumbled on this problem and reported it officially.

The workaround in the mean time consists of connecting to Microsoft Update and choose to stop using Microsoft Update. The PC will revert to using Windows Update and everything will be working normally again.

O.

Wednesday, July 21, 2010

My top 2 articles on the internals of broadcom-based routers

Embedded devices are energy efficient, and their limited memory and storage present some satisfying challenges. How have I missed this for all these years, I don't know, but it is time to play catch up. For a few weeks, I've been spending some of my free time reading on Openwrt and the WRT54GL and other devices of similar design.

Of course, flashing a custom firmware can be daunting enough for an average user, but an average geek like myself will want to know how exactly these devices work. There is a published book on the subject but upon reading the table of contents, I decided against buying it as I deemed it not technical enough.

So, I assumed there was information somewhere for people like me, info that didn't require me to read source code. And there is, but you have to search for it.

And what are the top two articles I found on the subject? Here they are.

1. First of all, there is a three year-old post entitled "Everything you need to know about Broadcom hardware" here in the Openwrt forums: https://forum.openwrt.org/viewtopic.php?id=11304

It is extremely informative on the boot process of these devices and it finally clarified for me how the CFE bootloader works. I didn't understand the SquashFS + JFFS2 combination details, thanks to this post now I do. You also should read about union mounts if you're not familiar with the topic (I wasn't, HP-UX does not support this!).

2. Then you should read about how VLANs and network interfaces work on the Broadcom platform -- this article is from the old OpenWRT wiki but well done, too. It is specifically for the Asus WL-500g but being a Broadcom design I can only suspect other routers are very similar, if not identical:
http://wiki.openwrt.org/oldwiki/openwrtdocs/networkinterfaces

This article explains why you have a bridge interface on your router. It especially shines in explaining how these routers isolate the interfaces cheaply using VLANs. In fact, there is only one twisted pair interface (eth0), the other one being the wireless antenna (eth2). I was under the impression that firewalls needed different and isolated interfaces, but the VLAN trick lets you do something similar on cheaper designs. And I guess it is good enough!

I might replace my m0n0wall PC soon in order to reclaim real estate in my utility room and save a few bucks on electricity. I just need a router, and disable the wireless radio. But I will NOT be purchasing a WRT54GL. Why? I'll tell you in a future post!

O.

Monday, July 12, 2010

Ah, Mom, I bricked my router!

Remember I was running OpenWRT on a Bufallo WLI-TX4-G54HP ? After playing with OpenWrt a bit I spent some time setting up a Ubuntu-based build environment to be able to build my own custom firmware.

There's no particular reason for building a custom firmware since the package I want to ultimately run fits on the JFFS2 partition. I just wanted to get my hands dirty. But gasp... the documentation for OpenWRT is sparse and disseminated in four areas: an unfinished HTML manual, an old Wiki, a new Wiki being slowly migrated from the old one, and the OpenWRT forums. One really has to spend some time reading through all of them to understand how everything works, and I've covered maybe 10% of that. And that's okay. I don't pay a cent for OpenWRT and it's a distribution targeted to power-users... If I wasn't looking for a challenge, I'd be running Tomato instead.

Anyway. It turns out that I bricked my device yesterday after flashing that darn custom firmware. I didn't solder a serial or JTAG port, wasn't really looking into doing this, so I couldn't do much to troubleshoot. One thing that no longer worked, and this was supposed to be my planned way out, was the 2-3 seconds it pings on 192.168.1.1 when it's at the CFE bootloader so that I can TFTP a correct firmware. Since it no longer did this, I couldn't do that to unbrick it.

I was about to throw it in the garbage but found somewhere in the DD-WRT forums that some Buffalo routers listen to 192.168.11.1. I tried this address and it worked! Now as to why it decided to listen to 192.168.11.1 while the first time it was 192.168.1.1, I don't know. I must have pressed the reset button 50 times on this thing so who knows what it ended up doing.

Back to square one, I have a router that works, but no custom firmware.

O.