Alice/O2 DSL and SSL

So, recently I wrote about how I had trouble connecting to google.com over HTTPS using my home DSL connection. I have narrowed the problem down and I must say that ppp is inocent.

I have tried to use the crappy router in router mode and even the fancy Fritz!Box7390 from my old VDSL connection both in modem and router mode and the problem persists. I have tried the original phone cable (you never know, right?) and any other thing imaginable: still fails to connect to google. But it's not alone! Trying amazon.com also fails from time to time! It still doesn't happen from my neighbor's connection or from my own connection for other servers (I tried, among others, facebook.com, deutsche-bank.de, visa.com, paypal.com, dkb.de).

 * About to connect() to amazon.de port 443 (#0)
*   Trying 178.236.6.38...
* connected
* Connected to amazon.de (178.236.6.38) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2): * error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
* Closing connection #0
curl: (35) error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

 * About to connect() to amazon.com port 443 (#0)
*   Trying 72.21.211.176...
* connected
* Connected to amazon.com (72.21.211.176) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
* Closing connection #0
curl: (35) error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

 * About to connecd() to amazon.com port 443 (#0)
*   Trying 72.21.211.176...
* connected
* Connected to amazon.com (72.21.211.176) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certifhcates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
*        subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
*        start date: 2010-07-15 00:00:00 GMT
*        expire date: 2013-07-14 23:59:59 GMT
*        common name: www.amazon.com (does not match 'amazon.com')
*        issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: amazon.com
> Accept: */*
>
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
* Closing connection #0


 * About to connect() to google.de port 443 (#0)
*   Trying 173.194.69.94...
* connected
* Connected to google.de (173.194.69.94) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* Unknown SSL protocol error in connection to google.de:443
* Closing connection #0
c5rl: (35) Unknown SSL protocol error in connection to google.de:443

 * About to connect() to google.de port 443 (#0)
*   Trying 173.194.69.94...
* connected
* Connected to google.de (173.194.69.94) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
* Closing connection #0
curl: (35) error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

 * About to connect() to google.com port 443 (#0)
*   Trying 173.194.69.113...
* connected
* Connected to google.com (173.194.69.113) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Sebver finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac
* Closing connection #0
curl: (35) error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record lac

So here is my new theory about who's the bad guy:
- Google, Amazon: nope, work for the rest of the world.
- PPP: no, tried without it and still fails.
- Crappy router: nope, also happens with fancy router.
- Alice ADSL: the only difference between my connection and the neighbor's connection is the access router to Alice's network. That MUST be it!

From my connection:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 52 byte packets
 1  alice.box (192.168.1.1)  2.437 ms  2.381 ms  17.397 ms
 2  lo1.br12.muc.de.hansenet.net (213.191.64.41)  26.054 ms gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  22.261 ms  26.177 ms
 3  inxs.google.com (194.59.190.61)  30.079 ms  30.047 ms  28.297 ms
 4  66.249.94.88 (66.249.94.88)  51.782 ms  34.389 ms  31.082 ms
 5  216.239.48.125 (216.239.48.125)  29.833 ms 216.239.48.117 (216.239.48.117)  32.006 ms 216.239.48.125 (216.239.48.125)  29.545 ms
 6  209*85.254.116 (209.85.254.116)  53.968 ms  30.843 ms 209.85.254.112 (209.85.254.112)  32.079 ms
 7  * * *
 8  google-public-dns-a.google.com (8.8.8.8)  32.152 ms  32.125 ms  30.507 ms

 PING 213.191.88.88 (213.191.88.88) 56(124) bytes of data.
64 bytes from 213.191.88.88: icmp_req=2 ttl=253 time=27.9 ms
NOP
RR:     192.168.1.4
        213.191.88.74
        213.191.88.88
        213.191.88.88
        213.191.64.41
        192.168.1.4


From neighbor's connection:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 52 byte packets
 1  172.24.128.1 (172.24.128.1)  2.520 ms  2.459 ms  2.429 ms
 2  172.24.0.1 (172.24.0.1)  2.428 ms  2.453 ms  2.414 ms
 3  192.168.1.1 (192.168.1.1)  5.133 ms  5.205 ms  4.880 ms
 4  lo1.br02.muc.de.hansenet.net (213.191.89.9)  28.328 ms  28.179 ms  28.098 ms
 5  gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  27.318 ms  27.837 ms  26.953 ms
 6  inxs.google.com (194.59.190.61)  136.017 ms  39.291 ms  39.645 ms
 7  66.249.94.86 (66.249.94.86)  38.188 ms  39.087 ms  38.489 ms
 8  216.239.48.125 (216.239.48.125   43.581 ms  42.874 ms 216.239.48.117 (216.239.48.117)  46.876 ms
 9  209.85.254.116 (209.85.254.116)  44.041 ms  45.064 ms  44.261 ms
10  * * *
11  google-public-dns-a.google.com (8.8.8.8)  42.816 ms  46.818 ms  46.312 ms

PING 213.191.88.88 (213.191.88.88) 56(124) bytes of data.
64 bytes from 213.191.88.88: icmp_req=1 ttl=251 time=36.1 ms
NOP
RR:     172.24.128.2
        172.24.0.4
        192.168.1.254
        85.181.69.47
        213.191.88.70
        213.191.88.88
        213.191.88.88
        213.191.89.9
        192.168.1.1


The whole thing about 213.191.64.41 disappearing from the 2nd traceroute hop after the first packet is quite weird, BTW. With an ICMP traceroute it does not happen:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 52 byte packets
 1  alice.box (192.168.1.1)  3.759 ms  2.364 ms  2.359 ms
 2  lo1.br12.muc.de.hansenet.net (213.191.64.41)  27.701 ms  157.436 ms  27.542 ms
 3  gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  23.166 ms  23.293 ms  22.792 ms
 4  inxs.google.com (194.59.190.61)  30.130 ms  29.518 ms  29.570 ms
 5  66.249.94.86 (66.249.94.86)  44.804 ms  38.765 ms  30.947 ms
 6  216.239.48.117 (216.239.48.117)  32.570 ms  31.293 ms  30.783 ms
 7  209.85.254.118 (209.85.254.118)  31.931 ms  31.347 ms  31.427 ms
 8  * * *
 9  google-public-dns-a.google.com (8.8.8.8)  32.889 ms  31.240 ms  32.917 ms

All this drives me to the conclusion that:
- 213.191.64.41is buggy as hell and Alice should be ashamed of having it there.
- 213.191.64.41is doing some really creepy targeted SSL tampering / man-in-the-middle / hijacking / manipulation and Alice should be seriously ashamed of having it.

Any ideas about the problem? How to solve it other that with a VPN past 213.191.64.41?

Crazy Google - PPPd - SSL BAD MAC error

UPDATE: follow up

Hi all. Long time no see. Just didn't have much to say lately. But now I do. So hi :)

A lot has actually changed lately, both at personal and professional level, but the relevant part is: I have a new ISP.  I moved and the awesome 50/10Mbit 1&1.de VDSL was no longer available, so now I have a much crappier 16/1Mbit ADSL by O2/Alice (after several months of borrowing the neighbor's WiFi). Also, instead of the fantasboulous FritzBox7390 I got a crappy Alice IAD 4412, or something whatever the thing it's called. It's 2.4Ghz only and 150 Mbit. And on top of that O2/Alice is soooo worried for some reason that I would sell the router on ebay to buy a yacht, that I have to return the damn thing at the end of the 24 month contract.

Of course the first thing I did was to disable everything internet related on the router, enable PPPoE passthrough and set up PPPoE on my linux box to act as a Torrent / Router / Firewall / Apache / Misc server. Since I had the same setup with 1&1 everything went pretty smoothly and all was fine. The End.

No, of course not. Everything did go smoothly, until I tried to use GMail. I got a nice SSL error page with the following message:

Secure Connection Failed
An error occurred during a connection to accounts.google.com.
SSL peer reports incorrect Message Authentication Code.

(Error code: ssl_error_bad_mac_alert)

I tried to google it, but since I use google with https by default, it happened for www.google.com too! After a F5 it would work again.

I thought it might be an iptables problem but the usual clamp-tcpmss-to-pmtu did no good. Trying to debug I wrote the following crude script:

C=0 E=0; while [ $E = 0 ]; do curl 'https://www.google.com' --no-sessionid -v -1; E=$?; C=$((C+1)); echo $C; done

I ran it in multiple configurations of destination servers, hosts and connections. Since I still have access to the borrowed neighbor's wifi I also ran it there. It's worth mentioning that the neighbor uses the same ISP and a traceroute shows that the second router down the road is already the same, so basically what's different is the ppp method (me - pppd through crappy router, he - crappy router directly).

Result: it fails ONLY when:

• I use my connection (pppd though router), doesn't matter if it's a NATed machine or the server itself. Ran over 11k times from other connections, no problem.
• I connect to google servers (accounts.google.com, www.google.com). Ran over 2k connections to other https servers from same connection: no problem.

So who is to blame?

• Google: no, it works fine from my work maciine and the neighbor's WiFi.
• pppd: no, it worked before with 1&1.
• Alice ADSL: no, the neighbor has Alice as well.
• Crappy router: no, it works fine when connecting to facebook, yahoo, deutsche bank, etc.
• Combination of all of the above: well, it works sometimes.

Solution? Sadly, I have none. I have a packet capture that shows exactly when the problem happens most often:

• Client Hello
• Server Hello
• Server Certificate, Server Key Exchange, Server Hello Done
• Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message (encrypted MAC of handshake).
• Server issues SSL Alert: Bad Record MAC.

Googling did not help either. Some suggest changing the clock would help, but same client fails only on a specific connection. Anyway, I synced all clocks of all involved machines: no joy. Clearing the cache: curl doesn't even have cache. Anyway, it didn't help. The closest online discussion of the problem is this thread. On other threads, some people hint that the problem is dependent on the particular connection, but nobody offers a decent solution.

I know it's a long shot, but: does anybody out there have an idea on how to fix this? Even a hint towards a method to further debug it would be greately appreciated. Problems for a good debug method:

• MAC is over random numbers: any comparison with different server/connection handshakes is useless.
• Since it is connection dependent client side errors are rather impossible.
• The sent MAC is encrypted, it's hard to analyze with wireshark.

The last ideas I have is to capture the ppp packets and compare if contents change over wlan0 contents (unlikely, since only google complains (only google checks?? unlikely...)), or try a different router/set the router in gateway mode instead of pppoe modem...

As said before, any idea will be appreciated!

Kernel version affects power consumption, confirmed.

Just an update on my last post. Some websites like H-Online (via phoronix) have catched up about what I already realized. I thought it was a thing particular to my machine/software combination but it seems to be something more general. I hope it gets fixed soon and I can update from my good-old 2.6.34.8 :)

Energy management in Linux: kernel version

UPDATE here.

Continuing from this post I want to show how the choice of a kernel version can have an important impact on the energy consumed by a computer (in my case, a Lenovo x200s).

I've been working on the battery quite often lately and I have noticed that the power consumption can vary quite a bit from kernel to kernel. This was of course a very subjective appreciation as the load could vary, the number of firefox tabs, the task I was doing or even how fast did I type.

The other day, however, after updating to kernel 2.6.38 i realized that idling, the computer barely went under 7W. I remember perfectly that "before", it could idle at aroung 6.0W, even with the wifi on, and now it was off. I decided to try an older version, and decided for 2.6.34. This is because from 2.6.35 to 2.6.37 there has been a very nasty bug that prevented my Intel Wifi 5300 agn card from injecting packets do to the famous -1 bug. Yes, I do audit my own wifi very often, why you ask? ;)

So I hacked the PKGBUILD file a bit and installed a custom 2.6.34.8 kernel along with my custom 2.6.38 one. I booted the laptop, turned the wifi off, closed Dropbox (powertop doesn't like it) and let it sit idle for a while. After a few minutes I closed the lid, previously deactivating sleep-on-close, to see how turning the screen completely off affects thigs. You can see the results on the following graph:

Energy consumption on a Lenovo x200s, KDE 4.6.1, WiFi & Bluetooth off, SSD disk, Screen 6/15 -> off

.

The result was so different that I used the .config from the 2.6.34 kernel to recompile the .38 and see maybe I missed something. As you can see from the blue line, that is not the case, the .38 kernel just consumes consistently 1W (~20%) more than the .34 version...

Take this results as they are: two different kernel versions with a particular custom configuration on a particular hardware.

I am NOT saying that kernel 2.6.34 is more energy-efficient than 2.6.38 as a general rule.
I AM saying that some kernel versions are more efficient than others on some hardware - test your versions on your hardware and pick the one that works best for you.

Too hipster

Lately there have been lots of hipster jokes on the interwebs. I myself got this funny idea about a geek-hipster joke and I though of making a small strip. After a while with Gimp, I proudly present:

[Click the image to see the original 3 scene file]

 Look, I'm an artist now! I have my own web-strip! :D

BeagleBoard-xM u-boot without serial cable - USB console

This is a note-to-self post, if you find it useful, you're welcome. If something is not clear, just ask.

Background: I got a BeagleBoard-xM but I had no serial cable and didn't want to get one (the shop is too far, internet store shipping is too slow). The thing connects via USB to the computer, and many devices implement serial over USB, so I thought "well, I'll connect the thing and as soon as it powers up I will get a /dev/ttyUSB0 to connect and interact with the bootloader/kernel". No luck. From my previous experiences with foneras I also tried an ethernet connection, in case it comes with ssh by default, but that didn't work either (the thing comes with a very small test implemetation that doesn't even power up the ethernet hardware).

Ok, lets do some RTFM. Done. Looking aroud, turns out that there is in fact a project for a USB console. I tried it but something was so wrong that it didn't even boot. Since people were reporting success with it, I assume that is some change in the xM version that makes it incompatible. and the last commit to the git repo was in mid-2009, so there was little hope that way. Next...

Short version

Turns out that the angstrom demo page contains almost everything needed. Download MLO, u-boot.bin, put them on the boot partition of the SD card as described in the wiki and jump to the boot.scr section.

Long version

Cross compile

First problem is getting cross compiling to work. We have a x86, we want to get arm code, gcc is not enough. There are many compilers and they have their differences.

For Arch, I used the package "arm-2010-arm-none-eabi 2010.09-1" from the AUR, which is this version. It fetches the i686 version so I used an Arch VM for compiling.

To use cross compiling, invoke make with "CROSS_COMPILE=arm-none-eabi-" parameter.

WARNING1: The name may differ, for older versions is "CROSS_COMPILE=arm-none-linux-gnueabi-". For any linux "locate eabi | grep gcc" should solve your problem, in Arch "pacman -Ql PACKAGE_NAME | grep bin" will do the trick even better :)

WARNING2: It turns out that the 2010 version has a nasty bug - or maybe it's something with my VM system - and it doesn't use the cross-assembler by default. Try to compile something and it keeps dying:

Assembler messages:
Fatal error: Invalid -march= option: `armv5'

Of course it's not valid, since it's calling the x86 assembler. I worked around it with the following script:

$ emacs /usr/local/bin/as

#!/bin/sh                                                                                
for i in $@; do
    echo $i | grep "\-march=arm" > /dev/null;
    if [ "$?" == "0"  ]; then
        /usr/bin/arm-none-eabi-as $@
        exit $?
    fi
done
/usr/bin/as $@
exit $?

Just make sure that /usr/local/bin is before /usr/bin in your $PATH, and you're good to go.

U-Boot

So, now we need that u-boot configures the USB OTG as a serial device and listens to it. And the only project aimed at it so fails hard on the xM that it doesn't even boot. Let's start with the wiki:

Mainline U-Boot has good support for BeagleBoard (except for revision C4; see note below).
[...]
Note: For experimental U-Boot patches not ready for mainline yet, Steve's Beagle U-Boot git repository is used to test them. [This was the omap3-dev-usb version no longer mantained that faile hardly]
[...]
Note: For beagleboard revision C4, above sources will not work. USB EHCI does not get powered, hence devices are not detected... get a patched version of u-boot from http://gitorious.org/beagleboard-default-u-boot/beagle_uboot_revc4/ (Update on April 23 - 2010: This repository has been superseded by the U-Boot version found at http://gitorious.org/beagleboard-validation/)

Ok, so I understand that the mainline is superseeded by the omap3, which are superseeded by the beagleboard-validation repository. Very well.

Let's checkout the BeagleBoard validation which has the validation code.

It looks promising, since the default git branch is called "xm".

$ make CROSS_COMPILE=arm-none-eabi- mrproper
$ make CROSS_COMPILE=arm-none-eabi- omap3_beagle_config
$ make CROSS_COMPILE=arm-none-eabi-
$ cp u-boot.bin /mnt/SDCARD/

It boots but unfortunately it fails to create a usb device. Last commit is June 2010, so I don't expect it being developed anymore. There are mentions to the musb device in the source code, it must be doable somehow. So I try the newest possible branch, jason 20110303 - doesn't even compile.
A bit less new, jason 20110302 - it works! When plugged to a computer it is detected as /dev/ttyACM0! Hurray... not so fast. When added boot.scr (see below) and connected with screen or minicom, it's silent. Damn, so close...
Let's go one more step back koen/beagle-2010.12. Compiles, loads (with boot.scr), creates the device... and answers! Yoohoo! But wait... (yes, there still is a catch) the output is semi-garbage! Well, let's try some other u-boot version...

Looking at the commit messages turn out that the upstream version is still being developed! All the steps again, at it goes silent. Tried with the latest stable release and it was almost-working still a bit unstable some letters were a bit off from the output, but pretty usable and functional.

boot.scr

By default the bootloader listens and speaks to the hardware serial console. To convince it to do otherwise we need to put a small boot.scr file on the sd card, just after copying u-boot.bin to it. To create the file we write the script to a text file:

$ emacs myscript.txt

setenv stdin usbtty
setenv stdout usbtty

Now we download any u-boot source and we issue a "make tools" command (no cross-compiling needed). After it finishes compiling:

tools/mkimage -A arm -T script -C none -d src.txt boot.scr

Then we copy the boot.scr file to the sd card in order to have a working usb bootloader console :D
In case you don't want to do all the stuff, here is a sample file:

$ hexdump boot.scr

0000000 0527 5619 0680 b4cc 744d b50a 0000 3100
0000010 0000 0000 0000 0000 e47f 58bb 0205 0006
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000040 0000 2900 0000 0000 6573 6574 766e 7320
0000050 6474 6e69 7520 6273 7474 0a79 6573 6574
0000060 766e 7320 6474 756f 2074 7375 7462 7974
0000070 000a                                   
0000071

Geek level: hard

Why boot.scr and not some other name?

$ emacs include/configs/omap3_beagle.h

#define CONFIG_EXTRA_ENV_SETTINGS \
        "loadaddr=0x82000000\0" \
        "usbtty=cdc_acm\0" \
        "console=ttyS2,115200n8\0" \
        "mpurate=500\0" \
        "vram=12M\0" \
        "dvimode=1024x768MR-16@60\0" \
        "defaultdisplay=dvi\0" \
        "mmcdev=0\0" \
        "mmcroot=/dev/mmcblk0p2 rw\0" \
        "mmcrootfstype=ext3 rootwait\0" \
        "nandroot=/dev/mtdblock4 rw\0" \
        "nandrootfstype=jffs2\0" \
        "mmcargs=setenv bootargs console=${console} " \
                "mpurate=${mpurate} " \
                "vram=${vram} " \
                "omapfb.mode=dvi:${dvimode} " \
                "omapfb.debug=y " \
                "omapdss.def_disp=${defaultdisplay} " \
                "root=${mmcroot} " \
                "rootfstype=${mmcrootfstype}\0" \
        "nandargs=setenv bootargs console=${console} " \
                "mpurate=${mpurate} " \
                "vram=${vram} " \
                "omapfb.mode=dvi:${dvimode} " \
                "omapfb.debug=y " \
                "omapdss.def_disp=${defaultdisplay} " \
                "root=${nandroot} " \
                "rootfstype=${nandrootfstype}\0" \
LOOK!-> "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
        "bootscript=echo Running bootscript from mmc ...; " \
                "source ${loadaddr}\0" \
        "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
        "mmcboot=echo Booting from mmc ...; " \
                "run mmcargs; " \
                "bootm ${loadaddr}\0" \
        "nandboot=echo Booting from nand ...; " \
                "run nandargs; " \
                "nand read ${loadaddr} 280000 400000; " \
                "bootm ${loadaddr}\0" \
#define CONFIG_BOOTCOMMAND \
        "if mmc rescan ${mmcdev}; then " \
                "if run loadbootscript; then " \
                        "run bootscript; " \
                "else " \
                        "if run loaduimage; then " \
                                "run mmcboot; " \
                        "else run nandboot; " \
                        "fi; " \
                "fi; " \
        "else run nandboot; fi"

Btw, you can change all kinds of fun stuff there, I recommend you take a look :D

Geek level: harder

Ok, so we have a self-made u-boot.bin and boot.scr. Why not have a MLO also? (MLO is the equivalent to grub's STAGE1 bootloader).
We grab the sources.

make distclean
make make omap3530beagle_config
make CROSS_COMPILE=arm-none-eabi-

This will result in a x-load.bin file. It's not ready yet, it needs to be signed (AFAIU, its just putting some size header, not real signing).

$ gcc scripts/signGP.c
$ ./a.out

And there we go! We can copy the x-load.bin.ift to the sdcard as MLO, then out u-boot.ini, our boot.src and we are good to go!

Next step

Have a kernel/init that allows USB console logging. Or, suboptimally, maybe just use a distro with a default ssh daemon...

Real world JavaScript solution

This is the final look of the code to solve the nasty performance problems with the instant search.

if(!$.browser.msie) { /* SORRY, BUT IE IS *SLOW* WITH JQUERY */
    uls = $("#metrics ul:visible"); /* Nasty hack: */
    uls.hide();                     /* 500x speedup on Chrome */
    if(text == "") {
        $(field_search).parents(".search_realm").find(".search_item").show();
    } else {
        $(field_search).parents(".search_realm").find(".search_item[id*="+text+"]").show();
        $(field_search).parents(".search_realm").find(".search_item:not([id*="+text+"])").hide();
    }
    uls.show();
} else { /* IE SPECIFIC ALGORITHM (x10 speedup on IE) */
    $( field_search ).parents(".search_realm").find(".search_item").each(function(){
        if(this.id.indexOf(text) == -1){
            $(this).hide();
        } else {
            $(this).show();
        }
    });
}

So, what happened here?
1. The horrible, horrible Chrome performance was due to a too-early rendering attempt. Hiding the containing ul makes Chrome stop trying to render after each element "reappears" and causes no flicker on the screen. The time goes from 12000ms to ~70ms for a 1549 element set.
2. IE didn't like jQuery. Well, don't make it use jQuery. Simple, huh? ;)
Now Chrome is an absolute performance champion with times 30/70, where as IE stays in the 320's and firefox in the 300/150's.