WRTU54G-TM running X-Wrt

20 Apr 2011 20:59

OK, so some time ago I bought a Linksys WRTU54G-TM. It's powered by Infineon ADM8668 processor (at 200 MHz) and has 64 MB RAM, which makes is pretty powerful router. Also it's really cheap. It looks like this:

The problem with this router is that there was no cool open source software for it. Linksys opened its sources, but I meant something like DD-WRT or OpenWRT. The problem is that the CPU architecture is different from for example the widely known and used WRT54G series.

Nonetheless there was some heavy work done to run a custom Linux firmware on it. After some successes, the author decided to port OpenWRT distribution to this router. And this is how it's done :-).

The OpenWRT is a command-line distribution of Linux for a bunch of routers. There is a web interface called X-Wrt which is installable as a opkg package to the OpenWRT systems, but there is no real information of how to install it on specifically WRTU54G-TM.

The good news is it can be done, the bad news is you have to hack it a little (but only very little). So let's go.

First, you need to "update" the software of the router to the OpenWRT version. The reference here is: http://wiki.scottn.us/wrtu54g-tm. Just log in to the router WWW interface, select Administration » Firmware Upgrade and choose this file wrtu54g-tm-openwrt-devel-b5.bin (download it from http://wrt.scottn.us/wrtu54g-tm-openwrt-devel-b5.bin).

This takes a while. Router then reboots. Give it a few minutes to load and install. After that the power LED keeps blinking which is probably a bug (in the official firmware, the LED blinks while the system is loading, but once it's up it lights still).

Connect to one of 4 Ethernet ports and you should be given an address IP in the 192.168.1.* network. If not, assign yourself one (for example 192.168.1.10). Then you can confirm the router is up, by pinging it:

ping 192.168.1.1

Trying to ssh to it will reveal you can't really do it, since you don't know the root password. This is tricky, but you need telnet to the router:

telnet 192.168.1.1

You'll be given the root shell. Set the password:

passwd

You'll need to enter the password twice for confirmation. Don't forget it :-).

Now you can ssh to the router:

ssh root@192.168.1.1

Deal with the RSA "host not known" warnings etc, and supply the password you just set.

If you connected the router to the network (by Ethernet cable to the "Internet" port) and your ISP has DHCP server, you should already have the Internet connectiong:

ping google.com

If you need to supply the static IP address, edit the following file:

/etc/config/network

You can use vim (busybox version) editor:

vim /etc/config/network

wan network corresponds to the Internet connection, while lan to the 4-port switch.

In this scenario it's possible you also have to supply the DNS servers, so instead of checking the Internet connectivity by pinging google.com, ping some IP address, like:

ping 8.8.8.8

Once you have the Internet connection, you can update the packages repositories, so you can install the X-Wrt interface:

mv /etc/opkg.conf /etc/original.opkg.conf
cat > /etc/opkg.conf

Enter the following:

src/gz adm8668 http://wrt.scottn.us/packages
src/gz snapshots http://downloads.openwrt.org/snapshots/trunk/brcm47xx/packages
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
arch all 5
arch brcm47xx 10
arch adm8668 20

… and press Ctrl-D. Your /etc/opkg.conf file should now contain the lines above. Update the repositories:

opkg update

Install the X-Wrt, which is packed in package named webif:

opkg install webif

Now if you point your web browser to http://192.168.1.1/ you should have a poor 404 page. It seems the permissions of the /www directory are wrong. I just did that to fix the problem:

chmod -R a+rX /www
/etc/init.d/uhttpd restart

Now you can log to the Web interface in with your login (root) and password.

You can now play with the router settings using the browser :-). Much simpler.

References:

http://wiki.scottn.us/wrtu54g-tm
http://wiki.openwrt.org/doc/start

Comments: 0, Rating: 0

Ubuntu 11.04 Beta 1

08 Apr 2011 21:05

Let's talk about Ubuntu 11.04 Beta 1. Honestly I don't think it really should be beta already. It just doesn't work for me. I think the only reason the "release" is called beta is that it's April already and the stable version of the system should be delivered to the end of it to justify the 11.04 name/version.

Let's start from the beginning. I'm having a Sony Vaio laptop with dual graphics system. During boot I can switch if nVidia or Intel graphics card is used. While on nVidia card, I didn't encounter any problems but the thing in "Extra Drivers" no nVidia card was detected. I'm not sure, maybe this "automatic" 3rd party driver installation is only activated after a real install.

I really wanted to see the new Ubuntu interface, so I switched to Intel graphics card and rebooted the machine. After a while I was able to "Try Ubuntu", I started the Firefox and then I noticed I don't have a network connection configured, so I clicked the network manager icon, chose my wifi network and tried to enter the password, but this caused compiz to close unexpectedly. Multiple times. After I managed to click "cancel" button the window decorations were gone and keyboard focus was not passed to clicked field, which made my system unusable. The standard shortcut to run command in Ubuntu: Alt-F2 didn't work either.

This was a pretty short test, but not passed at all. Ubuntu 11.04 doesn't deserve beta status, there are stability issues. For example trying to suspend the laptop in nVidia mode (without any commercial drivers) froze it instead so i had to reboot :-(.

Comments: 0, Rating: 0

Wikidot Wallart

07 Mar 2011 19:30

We're changing the office soon. This is one of ideas we have of what to put on the walls there:

Comments: 2, Rating: 1

Collectd: performance monitoring on servers

24 Jan 2011 19:17

As I mentioned on official Wikidot blog we use collectd to monitor the servers health, so that we can notice some problems and often prevent some disasters.

What's collectd

Collectd is fairly simple when it comes to the design. It's designed to just:

• initialize plugins with configuration data
• ask "read" plugins for data at configurable time intervals
• accept data from "read" plugins
• forward collected data to "write" plugins
• forward notification to "notification" plugins if data returned from read plugin is outside configured threshold

Some plugins comes right in the collectd packages:

• read plugin: system stats, like CPU, load, memory, disk usage etc
• read plugin: exec: runs configured command to fetch some data (read below)
• write plugin: save collected data to RRD files (it's easy to make graphs out of them)
• read-write plugin: network — passes data from one server to another one (useful to collect data from many servers on one machine)
• notification plugin: send email if some statistics is out of defined bounds

Amazing graphs

A number of WWW (also desktop-GUI) interfaces to RRD files that are generated by collectd exist, but none of them is perfect :-(. One we found one of the most exciting is Jarmon. But even also sucks at some things.

I think this project should be improved at this area. It's not really collectd core (as the WWW interface is only to display the rrd files, so this is already outside collectd), but nice screenshots mean a lot when you decide what monitoring software to install.

Ability to easily monitor "your own custom stuff"

The exec plugin runs a script (or executable, it doesn't really care) that is expected to produce statistics data. The binary should return at least one line that looks like this:

PUTVAL "myhost/mystats-stat1/gauge" interval=10 1179574444:666.44

• myhost is host name — used to group stats by host (useful when one machine collects data from many hosts)
• mystat is the plugin name — actually the plugin is exec, but when collectd processes THIS line it sets the plugin name to mystats (useful to note from which exec script the data comes from)
• stat1 is the datum you return value for — one plugin can return multiple values, for example a plugin that return how much of the file system is used would return one value for each mounted file system
• gauge — this was experimentally chosen as most universal type of data
• interval=10 — this data is generated each 10 seconds
  NOTE: if the script ends in less than this interval, collectd will launch another process to generate new values
• 1179574444 — current epoch time (date +%s)
• 666.44 — datum value (given gauge is used, this can be float or U for non-counted for some reason)

Full protocol definition can be found at collectd wiki.

Tricks on how to write "exec" plugin

There's official documentation of how to write such a plugin, but a simple plugin can be written without (almost) any knowledge. Just get your favorite scripting language language and go.

1. Don't trust COLLECTD_INTERVAL and COLLECTD_HOSTNAME. These environmental variables should hold what's configured collectd interval and hostname, but for some reason, they seem not to. Not a big deal, use command hostname to see what's the hostname and decide yourself how often you need to calculate given value.
2. For simplicity print value(s) once and just exit. Collectd will periodically run your script. If you keep your script fast or make the interval big, this should not be a problem. From my experience, it's not easy to create a plugin that produces values continuously. So unless you have a good reason don't try.
3. Unless you need, don't use other value type than gauge. It's universal and just works.
4. Test your script manually (by running it). It should (ideally) instantly print one line, like the example one above and exit with code 0. No standard error, no verbose stuff, no fancy options etc.
5. If you want, you can get configuration parameters of your script by command line arguments — write actual parameters in collectd.conf then.

Let's see at example/template script then:

#!/bin/bash

hostname=`hostname`
date=`date +%s`

# don't use "-" in those names:
plugin=myplugin
data=somedata
interval=60 # seconds

# compute the value:
value="30.44"

echo "PUTVAL \"$hostname/$plugin-$data/gauge\" interval=$interval $date:$value"

And that's all. You need to find some fancy (but not too fancy of course) name for the plugin and a way to compute the actual value :-).

Notice if the value won't be generated in the interval, that data is considered lost and if you have any thresholds for this values set, you'll get a notification about missing value (and then another one when it's back).

But how exactly looks section in threshold.conf that sets thresholds for such exec plugins:

<Threshold>

# Any value returned by plugin "myplugin"
# warning if value > 200
# failure if value > 400
<Plugin "myplugin">
    <Type "gauge">
        FailureMax 400
        WarningMax 200
    </Type>
</Plugin>
# Specific value (somedata) returned by plugin "myplugin"
# warning if value < 20
# failure if value < 1
<Plugin "myplugin">
    Instance "somedata"
    <Type "gauge">
        WarningMin 20
        FailureMin 1
    </Type>
</Plugin>

</Threshold>

Consult the documentation (or the actual file) for other options.

Bottom line

Collectd is worth trying, but you need to be prepared not everything is going to be pretty from the start. The system allows you to write your own data sources and once you know the tricks (see above) it's damn easy and still very reliable, so it's definitely a monitoring solution that's worth trying.

I hope by listing those tricks I learned while working with collectd I'll make at least one life a bit easier :-). I need to say, that collectd was quite easy to start with, but as problems arose, we were about to switch to some other monitoring solution, but now after finding our way with it, we'll probably stay with it for a while.

Comments: 1, Rating: 0