Monday, August 7, 2017

Hungarian Telenor's D-Link DWM-222 4G Mobile Broadband Modem on Ubuntu 16.04 Linux

D-Link DWM-222 on Linux

I recently had to use the D-Link DWM-222 modem sold by Telenor in Hungary. Of course plugging in and waiting did not bring nothing... so here you go step-by-step instructions for setting it up.

USB Mode Switch

The way these dongles work is that first they pretend to be a flash drive, containing the drivers. First, it must be non-standard, as Linux does not mount it automatically. Second, the drivers are Windows only... very helpful.

On Windows, after having the driver installed, it instructs the dongle to switch from being a flash drive ("USB Mass Storage" device) into an USB-to-Serial device, from which point it becomes a simple modem. Yes, you heard correctly, back to the 90's, when modems (remember the sound? :) were accessible on a serial port, with AT commands, using ppp interface! Guess what. We still have to use AT commands. Oh, the nostalgia.... 

So, we just need to give the instruction to the modem to do the switch. USB_ModeSwitch to the rescue!


Thankfully to Josua Dietze (make sure to visit his Draisberghof!), we have the utility right at hand. Ubuntu 16.04 does not have the most recent version supporting the DWM-222, so we need to download, compile and install it:

First, the dependencies (on Ubuntu I only needed this):

$ sudo apt install libusb-1.0-0-dev

Download and install -- check for recent link:

$ wget
 2017-08-07 12:51:38 (634 KB/s) - ‘usb-modeswitch-2.5.1.tar.bz2’ saved [259123/259123]
$ tar xfj usb-modeswitch-2.5.1.tar.bz2
$ cd usb-modeswitch-2.5.1/
$ make
 cc -o usb_modeswitch usb_modeswitch.c -Wall `pkg-config --libs --cflags libusb-1.0`
sed 's_!/usr/bin/tclsh_!'"/usr/bin/tclsh"'_' < usb_modeswitch.tcl > usb_modeswitch_dispatcher
$ sudo make install

Verifying the Switch

Having usb_modeswitch installed, the switch should occur automatically whenever the modem is plugged in.

Before the switch, the operating system sees USB device 2001:ab00 listed:

$ lsusb
Bus 001 Device 002: ID 2001:ab00 D-Link Corp.

...after the switch, this should turn into 2001:7e35:

$ lsusb
 Bus 001 Device 002: ID 2001:7e35 D-Link Corp.

Registering the Serial Interface

After having the switch done, we still do not see the new serial ports (/dev/ttyUSB* devices). As far as I get it, this is because Linux kernel's usbserial module still does not recognize this USB device as a serial port provider. Rectification is easy, we need the option kernel module to tell the Linux kernel that hey, this is a serial port provider! Easy-peasy, lemon squeezy:

$ modprobe option
$ echo 2001 7e35 > /sys/bus/usb-serial/drivers/option1/new_id

Automating the Registration

Oh, it would be so great if we could just have a way to tell Linux to run these commands anytime the device is detected... but hey!! This is what udev is for! Let's get to it:

$ cat > /etc/udev/rules.d/99-dlink-mobile-connect.rules
ACTION=="add", ATTRS{idVendor}=="2001", ATTRS{idProduct}=="7e35", RUN+="/sbin/modprobe option" RUN+="/bin/sh -c 'echo 2001 7e35 > /sys/bus/usb-serial/drivers/option1/new_id'"(press ctrl-d here to end the input)

If you did everything correctly, you should have your broadband modem detected everytime you plug it in. Don't you just love Linux? :)

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_