Friday, February 12, 2016

Debian/Ubuntu's ifupdown: If WPA2-PSK Only Works When Specifying SSID Manually

Pre-requisite: you use Debian's (also Ubuntu) ifupdown architecture, i.e. not using Network Manager, but just specifying connectivity details in /etc/network/interfaces -- including WPA passphrase (pre-shared key aka PSK).
Also, for security purposes you have configured your router to hide your SSID.

Symptom: computer starts up and but does not connect to your WiFi. However, it does connect if you set the SSID manually, that is with:
iwconfig wlan0 essid YourSSID
Solution: also add this line to your interface configuration (/etc/network/interfaces file):
wpa-scan-ssid 1

Debug steps - what happens in the background:

First I found out that ifupdown actions can be invoked manually by issuing ifup or ifdown. WPA setup and authentication is done by the otherwise excellent wpa_supplicant program, which can be invoked in two ways:
  • specifying a configuration file
  • starting up as a daemon and remotely supplying configuration options -- using wpa_cli, its command line interface
ifupdown uses the latter approach, issuing wpa_cli commands in order to:
  • add a new network (ie set of parameters)
  • specify each parameter (like SSID, passphrase, etc)
  • start connectivity
In the last step, wpa_supplicant will start scanning for the SSID specified, and will only start setup and negotiations after a router has been found.

Regarding scanning, it supports two methods: one just checks among the visible SSIDs, the other, more time consuming method is able to find access points with hidden SSIDs. You can guess which method is the default...

Of course, all this is nicely documented in /usr/share/doc/wpasupplicant/README.modes.gz; quote:

In order to be able to associate to hidden ssids, please try to set the option 'ap_scan=1' in the global section, and 'scan_ssid=1' in your network block section of your wpa_supplicant.conf file.
If you are using the managed mode, you can do so by these stanzas:

iface eth1 inet dhcp
        wpa-ap-scan 1
        wpa-scan-ssid 1
        # ... additional options for your setup
Finding the documentation is a different matter. To be noted, in my case the wpa-scan-ssid option was enough to solve the issue and have wpa_supplicant find my hidden SSID, the wpa-ap-scan option was not necessary.

Wednesday, August 5, 2015

IRTrans with Samsung Air Conditioner

How To Use IRTrans with Samsung Air Conditioners

I desperately tried to google the corresponding .rem file, to no avail - so I had to create a solution myself.

You can find everything, including a short description on my GitHub repo, here:


Thursday, November 28, 2013

Cross-compiling Linux Kernel for Raspberry Pi on Ubuntu 12.04


Why recompile the kernel?
Because few drivers might be missing. In my case, the eGalax USB touchscreen driver had to be enabled.

What is this cross compilation thing?
It simply means compiling on a different architecture (eg, Intel processor). You want this as your laptop is most probably 5-10x faster than the Raspberry.

What is your setup?
In this tutorial I assume a separately running Raspberry Pi connected to the network, with the hostname raspberrypi.


Install the compiler (for arm) and the tools necessary:

ubuntu$ sudo apt-get install git-core gcc-arm-linux-gnueabi make ncurses-dev

I also created a symlink for the cross-compiler. This is needed as the CROSS_COMPILE kernel flag takes the prefix "arm-linux-gnueabi-", and appends "gcc" to it, without the version number.

ubuntu$ sudo ln -s /usr/bin/arm-linux-gnueabi-gcc-4.6 /usr/bin/arm-linux-gnueabi-gcc

Obtain and uncompress the kernel source:

ubuntu$ wget --no-check-certificate
ubuntu$ tar xvfz rpi-3.10.y.tar.gz
ubuntu$ cd linux-rpi-3.10.y

Note: 3.10.y is the current stable branch at the time of the writing (November 2013), you might want to change this.


Copy and uncompress the current Raspberry kernel configuration (your scp usage might vary, I assume default hostname and username):

ubuntu$ scp pi@raspberrypi:/proc/config.gz .
ubuntu$ gunzip config
ubuntu$ mv config .config

Now comes the tricky part. Since the kernel we are compiling is (probably) more recent than the one we have on the Raspberry, more configuration choices have been added. The make the kernel ask for the new config options only, issue:

ubuntu$ make oldconfig

Follow the instructions, you should be safe to accept the default answers offered. When done, you can optionally run the shiny menu-based configuration to change your needs -- eg, to enable the touchscreen driver:

ubuntu$ make menuconfig


This can take several hours. If you have multiple CPU cores, to use all of them, make sure to specify -jN, where N is number of cores + 1. Eg, a dual-core machine should use -j3.

ubuntu$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -j3

When done, we should have the kernel and all the modules built. The module binaries must be installed to separate them from the source files:

ubuntu$ mkdir ../modules
ubuntu$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- INSTALL_MOD_PATH=../modules modules_install

Upgrade the Raspberry Pi Binary Firmware

On the Raspberry Pi, back up the /boot directory containing the boot loader and the current kernel abd the /opt directory containing the VideoCore firmware:

raspberrypi$ sudo cp -R /boot /boot.bak
raspberrypi$ sudo mv /opt /opt.bak

Warning: without these files your Raspberry will not be bootable.

Obtain the most recent Raspberry Pi firmware (takes long, huge repository -- you might choose to clone this to Ubuntu and scp over the required files only):

raspberrypi$ git clone git://

...then copy over the most recent boot loader files:

raspberrypi$ cp firmware/boot/bootcode.bin /boot
raspberrypi$ cp firmware/boot/fixup.dat /boot
raspberrypi$ cp firmware/boot/start.elf /boot

...and the VideoCore firmware (assuming you are using hard float; use command  gcc -v 2>&1 |grep with-float=hard to find out; if it prints a line, you have hard-float configured):

raspberrypi$ cp -R firmware/hardfp/opt /

Note: this "firmware" is different to the module-loaded firmware that is included in the Linux kernel.

Upload the Kernel to the Raspberry

First, let's transfer the necessary files:

ubuntu$ scp arch/arm/boot/zImage raspberrypi:kernel.img
ubuntu$ scp -r ../modules/lib/modules raspberrypi:
ubuntu$ scp -r ../modules/lib/firmware raspberrypi:

Then let's move them to their place:

raspberrypi$ sudo cp kernel.img /boot
raspberrypi$ sudo cp -R modules /lib
raspberrypi$ sudo cp -R firmware /lib

You should be able to reboot now.

Alternative Choices

Kernel source can be obtained through git as well; this takes much longer though:

mkdir linux-rpi-3.10.y
cd linux-rpi-3.10.y
git init
git fetch git:// rpi-3.6.y:refs/remotes/origin/rpi-3.10.y
git checkout rpi-3.10.y

Also, instead of scp'ing to a running Raspberry, you might want to insert the SD card into your Ubuntu machine and copy the files over. (You must obviously do so if the Raspberry does not boot.)


Saturday, November 9, 2013

Using a 800x480 LCD with Raspberry Pi

Is simple. Into /boot/config.txt, put:

#increase HDMI signal strength (just a black screen if not set!)
#remove black borders
#set specific CVT mode
hdmi_cvt 800 480 60 6 0 0 0
#set CVT as default

My LCD is the Lilliput 669GL -- works like a charm.

Friday, July 12, 2013

RealTek RTL-8029 under Linux 3.x

A short note with a solution of a 1.5-hour long struggle.

If you have an older Realtek 8029 network interface card, you need to use the ne2k-pci kernel module. With stock kernels shipped with most distributions today this should be no problem, they usually have this module readily precompiled.

However, if you are compiling the kernel yourself, it can be tricky to find the driver among the Linux Kernel configuration options. So here it is:
Device Drivers => Network Device Support => Ethernet driver support => National Semi-conductor devices => National Semi-conductor 8390 devices => PCI NE2000 and clones support
Note: as the help of this option says, this kernel module should be used for all of the following network cards: RealTek RTL-8029, Winbond 89C940, Compex RL2000, KTI ET32P2, NetVin NV5000SC, Via 86C926, SureCom NE34, Winbond, Holtek HT80232, Holtek HT80229.

Wednesday, June 26, 2013

C/C++: Async TCP Connection Failure Detection on OSX / BSD

As the hard-core C programmers know, the connect(2) function can operate in to modes:

  • blocking: the program will stop running until connection succeeds/fails/times out (latter can be as long as 30 seconds!)
  • non-blocking: connection is initiated only, and the socket's file descriptor can be checked if connection has completed or not (as a standard, check for writability with select(2)).
Whenever select(2) returns, we must be able to check if our connection attempt was the triggering event, that is, if the connection attempt has been finished or not.

One might believe the manuals and tutorials, which basically tell following:

To check the state of an asynchronous connection attempt, use getsockopt(2) to retreive the SO_ERROR value. If this is 0 (ESUCCESS), the connection has succeeded. If EINPROGRESS, the attempt has not been finished yet. Otherwise, the attempt has failed.
Problem: this is only true for Linux. On BSD (and yes, this includes OSX), when a connection is refused, getsockopt(2) will still return ESUCCESS. Even more strange, a write attempt to this socket simply makes the program exit - without a core dump.

What then?

According to this excellent summary, we are best off double-checking the state of the socket. The best option listed is issuing a getpeername(2) call, which either succeeds (connection established!) or fails (connection failed).

In code:
  // assuming connection is already in progress, select(2) has returned,
  // socket file descriptor is fd_:

  int err = -1;
  int len = sizeof(err);
  if (getsockopt(fd_, SOL_SOCKET, SO_ERROR, (int*)&err,
                 (socklen_t*)&len) != 0) {
    handleConnectionError("getsockopt error");
  struct sockaddr sa;
  socklen_t saLen = sizeof(sa);
  int gpnErr = getpeername(fd_, &sa, &saLen);
  if (err == 0 && gpnErr == 0) {

  if (err == EINPROGRESS) {
    // do one more select(2) run on the file descriptor fd_

Tuesday, June 18, 2013

Speeding Up Motorola Droid 2 / Milestone 2

I expect my phone to run smooth and fast. I mean, it _has_ the hardware to do so! My old server has a Pentium III processor ticking at 1GHz, it has 512M RAM. I even used Eclipse + Tomcat to code a web application for my thesis program in java!

The Milestone 2 has similar specs. Okay, different architecture, but still, I expect it to be pretty fast. And since I installed Viber, it became unusable and slow, sometimes having to wait ~10 seconds just to see the dialpad appear!

Buy a new phone? Galaxy S4 or Xperia Z, for ~$1000?? Naaaay.

Jelly Bean: a New Phone for Free

Thanks to the guys at, Jelly Bean, the shiny new operating system is available for the Milestone 2 as well, via the CyanogenMod custom ROM.

Installing CyanogenMod in X Steps

  • Root the phone; see for details. If you're paranoid, download the rooter from here and compile and run yourself.
  • Install Droid 2 Bootstrap Recovery; download for free from here (I did this manually, ie just gaining root on the phone but not installing the "su" command; just checking the error messages the installer gave me and typing the commands myself. Call me paranoid, but I like to see what's being done.)
  • Download CyanogenMod onto the sdcard - from here:
  • Do the same with the official Google Apps - from here:

Speed Issue

While very happy with the slick UI, all the new features of Jelly Bean, the phone continued to crawl after Viber got reinstalled. What now?
Fortunately, CyanogenMod has a great built-in option: you can change the CPU governor. If a CPU supports it, Linux can decrease the clock speed if there's no demand, to save battery. Go to System Settings => Performance => CPU Governor, and select "Performance". Also, tick the Set on boot option, to make this change permanent.
While the phone got much snappier, I did not notice considerably less battery time. I think this is due to the fact that when the screen is off (most of the time), the phone sleeps (ie, CPU speed has no effect), and when it's on, the CPU usage is high anyway - due to all the effects, etc.
Another tip: turn off background data (maybe enable it selectively for a handful of applications). This will save bandwidth and battery.
Update: recently I installed LINE, but I had to realize it drains my battery extremely fast. Switching back to "Ondemand" governor solved this issue.

CyanogenMod too Risky?

In this case, "just" root the phone, and install an application that is able to set the CPU governor. (If you're a Linux guru, edit the boot scripts yourself from the terminal to issue "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" on every bootup.)