Samsung Galaxy 5 USB Tethering in Slackware64 Linux with Pppd

Samsung Galaxy 5 (Android 2.1 Eclair) is different from other Android phone in the Galaxy lines of products. It doesn't act like a router by default like its more capable brethren, the Samsung Galaxy S. The problem with setting up this device in Linux is just like the Nokia E61
that I elaborated here a few years ago. That is: it has a vendor-specific AT command set to set up the device as a modem.

The following is the summary of the steps to use the Galaxy 5 as a USB modem:

1. Disable "automatic data connection" on the Galaxy 5. Deactivate: Settings | Wireless & networks| Mobile networks | Enable always-on mobile. Activating always-on mobile option will force the phone to use data connection (GPRS/EDGE/3G/HSDPA/HSUPA) whenever no WLAN coverage could be used. In that state, the phone acts as the endpoint of the data connection (usually a PPP connection). Because a PPP login account cannot be used by more than one device at a time in the same network, the PPP connection directly from the phone would effectively "disable" new PPP connection from a computer which uses the phone as a modem to connect. That's why you have to deactivate the always-on mobile option.


2. Prepare the configuration files for Galaxy 5


3. Watch syslog message in your PC/Laptop using the tail -f /var/log/message command


4. Connect the Galaxy 5 to your PC/Laptop with the USB cable


5. Choose Kies mode when Galaxy 5 ask for the operating mode


6. Syslog will display the phone as one of the tty device. In my case the device is ttyACM0


7. Run Pppd by using the tty device in the previous step as the tty device

Among the steps above, the ones which need further explanation are the first and the last steps.

The ISP used in this example is represented by the "indosatm2" string in all of the configuration files.

The configuration file that I use as follows.

The /etc/ppp/options is: (disabled options are not shown)

# /etc/ppp/options
# 
# $Id: options,v 1.4 1996/05/01 18:57:04 alvar Exp $
# 
# Originally created by Jim Knoble 
# Modified for Debian by alvar Bray 
# Modified for PPP Server setup by Christoph Lameter 
# Modified for Slackware by Pat Volkerding 
#
# Use the command  egrep -v '#|^ *$' /etc/ppp/options to quickly see what 
# options are active in this file.

asyncmap 0
crtscts
lock
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

The "peers" file (/etc/ppp/peers/im2_galaxy5) used to call the ISP as follows:

/dev/ttyACM0 921600 crtscts 
connect 'chat -v -f /etc/ppp/chat/im2_galaxy5_connect_chat'
disconnect 'chat -v -f /etc/ppp/chat/im2_galaxy5_disconnect_chat'
defaultroute name your_login debug noipdefault usepeerdns 

The "connect" chat file (/etc/ppp/chat/im2_galaxy5_connect_chat) as follows:

ECHO ON
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
ABORT 'ERROR'
ABORT 'NO ANSWER'
ABORT 'BUSY'
'' ATZ
OK 'ATE0V1&D2&C1S0=0'
OK 'ATS7=60'
OK 'ATS0=0'
'' ATZ
OK 'ATE0V1&D2&C1S0=0'
OK 'ATS7=60'
OK 'AT+CGDCONT=1,"IP","indosatm2","",0,0'
OK 'ATDT*99#'
CONNECT
~ ''

The "disconnect" chat file (/etc/ppp/chat/im2_galaxy5_disconnect_chat) as follows:

ECHO ON
ABORT 'BUSY'
ABORT 'ERROR'
ABORT 'NO DIALTONE'
SAY             "\nSending break to the modem\n"        
""              "\K"            
""              "\K"            
""              "\K"            
""              "\d\d+++\d\dATH"        
SAY             "\nPDP context detached\n"

The "connect" chat file is used to setup the Galaxy 5 (modem) to connect to the ISP while the "disconnect" chat file is used to "reset" the Galaxy 5 (modem) after the connection is closed.

The PAP secret file (/etc/ppp/pap-secrets) as follows:

# Secrets for authentication using PAP
# client        server     secret                  IP addresses
your_login          *     your_password               *

A Password BUG in Pppd v2.4.4 caused the PAP authentication to fail when your password contains the "@" character and you're using Samsung Galaxy 5. Eventhough the "@" is escaped with "\" in the "secret" column shown above, it will still fail to authenticate properly. The message in Syslog says the PAP authentication is successful. However, that's not exactly the case because the IPCP negotiation always failed. Though, other cellphone probably works just fine with Pppd 2.4.4.

Perhaps you're asking: where did I found the Samsung Galaxy 5-specific AT command-set shown in the chat file above. I found it in the modem log file in Windows when running tethering with Kies. This is the log file in C:\Windows\ModemLog_SAMSUNG Android USB Modem.txt

10-23-2010 03:18:58.312 - File: C:\WINDOWS\system32\tapisrv.dll, Version 5.1.2600   
10-23-2010 03:18:58.312 - File: C:\WINDOWS\system32\unimdm.tsp, Version 5.1.2600   
10-23-2010 03:18:58.312 - File: C:\WINDOWS\system32\unimdmat.dll, Version 5.1.2600   
10-23-2010 03:18:58.312 - File: C:\WINDOWS\system32\uniplat.dll, Version 5.1.2600   
10-23-2010 03:18:58.328 - File: C:\WINDOWS\system32\drivers\modem.sys, Version 5.1.2600   
10-23-2010 03:18:58.328 - File: C:\WINDOWS\system32\modemui.dll, Version 5.1.2600   
10-23-2010 03:18:58.328 - File: C:\WINDOWS\system32\mdminst.dll, Version 5.1.2600   
10-23-2010 03:18:58.328 - Modem type: SAMSUNG Android USB Modem
10-23-2010 03:18:58.328 - Modem inf path: oem30.inf
10-23-2010 03:18:58.328 - Modem inf section: SAMSUNG.Install
10-23-2010 03:18:58.328 - Matching hardware ID: usb\vid_04e8&pid_689e&mi_00&os_nt
10-23-2010 03:18:58.343 - 921600,8,N,1, ctsfl=0, rtsctl=1
10-23-2010 03:18:58.343 - Initializing modem.
10-23-2010 03:18:58.343 - DSR is low while initializing the modem. Verify modem is turned on.
10-23-2010 03:18:58.343 - CD is high while initializing modem.
10-23-2010 03:18:58.359 - Send: AT
10-23-2010 03:18:58.359 - Recv: AT
10-23-2010 03:18:58.359 - Command Echo
10-23-2010 03:18:58.359 - Recv: OK
10-23-2010 03:18:58.359 - Interpreted response: OK
10-23-2010 03:18:58.359 - Send: ATE0V1&D2&C1S0=0
10-23-2010 03:18:58.359 - Recv: ATE0V1&D2&C1S0=0
10-23-2010 03:18:58.359 - Command Echo
10-23-2010 03:18:58.359 - Recv: OK
10-23-2010 03:18:58.359 - Interpreted response: OK
10-23-2010 03:18:58.375 - Send: ATS7=60
10-23-2010 03:18:58.375 - Recv: OK
10-23-2010 03:18:58.375 - Interpreted response: OK
10-23-2010 03:18:58.375 - Waiting for a call.
10-23-2010 03:18:58.390 - Send: ATS0=0
10-23-2010 03:18:58.390 - Recv: OK
10-23-2010 03:18:58.390 - Interpreted response: OK
10-23-2010 03:18:58.390 - 921600,8,N,1, ctsfl=1, rtsctl=2
10-23-2010 03:18:58.390 - Initializing modem.
10-23-2010 03:18:58.390 - DSR is low while initializing the modem. Verify modem is turned on.
10-23-2010 03:18:58.390 - CD is high while initializing modem.
10-23-2010 03:18:58.406 - Send: AT
10-23-2010 03:18:58.406 - Recv: OK
10-23-2010 03:18:58.406 - Interpreted response: OK
10-23-2010 03:18:58.406 - Send: ATE0V1&D2&C1S0=0
10-23-2010 03:18:58.406 - Recv: OK
10-23-2010 03:18:58.406 - Interpreted response: OK
10-23-2010 03:18:58.421 - Send: ATS7=60
10-23-2010 03:18:58.421 - Recv: OK
10-23-2010 03:18:58.421 - Interpreted response: OK
10-23-2010 03:18:58.421 - Dialing.
10-23-2010 03:18:58.437 - Send: ATDT*###
10-23-2010 03:19:01.468 - Recv: CONNECT 115200
10-23-2010 03:19:01.468 - Interpreted response: Connect
10-23-2010 03:19:01.468 - Connection established at 115200bps.
10-23-2010 03:19:01.468 - Error-control off or unknown.
10-23-2010 03:19:01.468 - Data compression off or unknown.
10-23-2010 03:19:31.468 - Read: Total: 3711, Per/Sec: 122, Written: Total: 3553, Per/Sec: 117
10-23-2010 03:21:31.468 - Read: Total: 994835, Per/Sec: 8259, Written: Total: 83780, Per/Sec: 668

A note about the the chat configuration file

Anyway, perhaps what is not so clear in the chat file is the "~" character in the last line. It actually tells the chat script to expect a "~" (tilde) as a response after the
serial connection with the remote PPP endpoint is established.

The following excerpt from PPP-HOWTO (http://www.linux.org/docs/ldp/howto/PPP-HOWTO/x419.html)
explain about it.

8.3.3. The remote PPP process is slow to start

This one is a bit tricksy!

By default, your Linux pppd is compiled to send a maximum of 10 lcp configuration requests. If the server is a bit slow to start up, all 10 such requests can be sent before the remote PPP is ready to receive them.

On your machine, pppd sees all 10 requests reflected back (with the 8th bit stripped) and exits.

There are two ways round this:-

Add "lcp-max-configure 30" to your ppp options. This increases the maximum number of lcp configure packets pppd sends before giving up. For really slow server, you may need even more than this.

Alternatively, you can get a bit tricksy in return. You may have noticed that when you logged in by hand to the PPP server and PPP started there, the first character of the ppp garbage that appears was always the tilde character (˜).

Using this knowledge we can add a new expect/send pair to the end of the chat script which expects a tilde and sends nothing. This would look like:-

\~ ''

Note: as the tilde character has a special meaning in the shell, it must be escaped (and hence the leading backslash).

Another thing in the chat script is: Samsung Galaxy 5 will emit a "CONNECT" string when the serial connection
is established with the remote endpoint.

GNU Autotools Problems and Fixes

In the course of modifying an opensource source code recently, I found out that some GNU autotools (particularly automake and autoconf) "constructs" can cause compatibility problems. I'll explain two of them below.

First, the AC_CONFIG_HEADER construct.

Some macro extensions to the default Automake/Autoconf constructs uses the old AC_CONFIG_HEADER construct which has been superseded by AC_CONFIG_HEADERS in recent GNU autotools (in my case I'm using automake 1.10). Notice the change to plural form with addition of "S" in the end of the macro.

One particular annoying bug that I found is the widely used AX_PREFIX_CONFIG_H macro uses AC_CONFIG_HEADER in its older version (which is used in a lot of opensource project). Therefore, if you're migrating an old source code which uses this particular macro in its older incarnation, make sure you change the AC_CONFIG_HEADER macro to AC_CONFIG_HEADERS. Otherwise, automake will fail when you try to update the auto-generated Makefiles and the corresponding build scripts.

Second, the use of GNU make extension

Sometimes using GNU make extensions in Makefile.am file will cause portability warnings to be shown when you invoke automake. To prevent the warning those warnings, you can use the following construct:

AM_INIT_AUTOMAKE([-Wno-portability])

in your configure.ac/configure.in file.

Those are the most important things. Another rather important thing is updating the libtool-related scripts if the opensource source code uses libtool and you're actually migrating to newer autotools version from a very old one. It's as easy as invoking this:

me@my_machine:~/Projects$ libtoolize -c 

The "-c" switch instructs libtool to copy the libtool-related scripts instead of symlinking them. It's important to do so, to make sure the old libtool-related scripts updated accordingly and the new one will be included in the software package. This is especially important if you use some sort of Revision Control System (RCS) such as subversion, git or others.

That's it for now.

Combining GNU Autotools with Qt to One Build System

As you have probably aware, when you have a project that uses GNU Autotools (autoconf, automake, libtool) and Qt, there are two different build systems in use. First is the GNU autotools build system and the second is the Qt build system (Qmake, etc.).

The weakness of using two independent build system probably is not too obvious. However, when you start trying to build the whole project outside of the root directory of the source code, the build will fail. With GNU autotools itself, the build will be successful. Then how do you migrate from Qt build system to GNU autotools? It's simple, use Autotroll (http://tsunanet.net/autotroll/). Autotroll is a set of m4 file and makefile which will help you carry-out what qmake do. This way, the build system will be unified into GNU autotools build system. No more calls to qmake manually (or within a script you made).

Building Qt Application on 64-bit Multilib Systems

Some Qt application cannot build correctly on 64-bit multilib systems by default. For example, the Italc application (http://italc.sf.net). The problem is, the default search path for Qt library usually set to the 32-bit qt library whereas the default C++ (GNU g++) compiler is 64 bit one. To force the application build process to use the 64-bit Qt library, you must set the QTDIR environment variable to the path_to_64_bit_Qt_library. For example, in my machine this is how I build the Italc application:

darmawan@opunaga:italc-1.0.9$ QTDIR="/usr/lib64/qt" ./configure --prefix=/usr  --libdir=/usr/lib64
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
...

ICQ behind a proxy with pidgin

Using your ICQ account with Pidgin in network behind a HTTP proxy is not a straight forward matter. These are the settings which you should change on your ICQ account settings in Pidgin:
1. Change the Port in the Account|Modify Account|Advanced tab for the login.messaging.aol.com server from 5190 to 443.

2. Go to Account|Modify Account|Proxy tab and enter the correct host and port for your HTTP proxy. If the proxy needs an authentication, you should enter your username and password in that tab. Otherwise, leave the username and password blank.

That's it. Hopefully it solves your problem.

Fixing Slackware64 Console Video Mode Bug

I have just finished installing my machine (Athlon64 X2 4000+, 2GB RAM, ATI RS690G motherboard) when I found that the console went blank after logging-out from X. It takes me a couple of hours to figure out what's wrong because the console is just fine prior to starting the X server. After playing around with LILO, I found out that the it's the video mode that causes the bug. My LCD display cannot switch to the requested "default" video mode upon logging out from X. These are the steps to fix the video mode (I'm using LILO bootloader):

1. Edit /etc/lilo.conf and change the video mode to "vga=ask". This will force the dialog that let you choose the correct video mode parameter to pass to the kernel on boot.

2. Reboot the machine.

3. Assuming that you know the correct video mode for your display (resolution and color depth). Enter the correct video mode number when LILO ask for the video mode to be used. LILO will display the video mode supported by the display (acquired via EDID). Anyway, the number corresponding to the video mode is in hexadecimal value. For example, 1280x1024x16 (1280x1024 16-bit) corresponds to video mode number 365h (794 decimal).

4. Edit /etc/lilo.conf and change the video mode to the suitable video mode number. For example, if your display support 1280x1024x16, you should change the "vga=ask" in lilo.conf to "vga=794". In the preceding example, the video mode number in lilo.conf is in decimal.

5. Reboot to see whether you have a flawless console video mode.

That's it. With this, you should be able to fix or enhance the look and feel of your console in Slackware64 (or other Linux distro).

The Potential of Underclocking

This article from Xbitlabs which describes a detail about AMD Socket AM3 mini-ITX platform highlights the importance of underclocking the CPU in certain circumstances.

I didn't realize the benefits of underclocking previously. However, it's now clear that the reduced power consumption and heat obtained from underclocking opens new opportunity for several constrained systems. For example, for mobility applications and industrial application where the need for ultimate number-crunching capabilities are not the top priority.

One of the mobility application could be a mobile robot with constrained supply of energy with number-crunching need above the Intel Atom territory but could be met by an underclocked Athlon II X2.

In industrial application, it could be a process control board with high enough number-crunching needs but required to be in certain thermal envelope which could not be met by Intel Atom.

Another possibility tempting possibility is underclocking Intel Atom to be used in applications where high performance ARM/MIPS chips do not met the required performance characteristics, or certain x86-tuned code would be more suitable than porting the code to ARM/MIPS architecture.

Well, this is another possible solution that system designers could exploit in certain circumstances.

Adaptive Huffman FGK Algorithm Musing

A short test of the FGK adaptive Huffman algorithm described in J.S. Vitter's paper reveals that the single pass compression algorithm described in the paper (http://www.cs.duke.edu/~jsv/Papers/Vit87.jacmACMversion.pdf) doesn't update the frequency value in the root of the tree. However, it's not that important because what we need from the tree is only the encoding for every leaf in the tree, i.e. the encoding for the symbols.

The study of various compression algorithm in my spare time mostly motivated by curiosity and the possible use of such a knowledge in future reverse engineering tasks.

Fooling around with Ioquake3 game engine

I am a big fan of the Quake 3 Arena (Q3A) game. I stumbled upon the Ioquake3 opensource Q3A game engine. I thought it would be fun to play with the code and see what happened in the game. I decided to mod the Plasma gun effect to use BFG style "bullets". That should increase the level of fun. Well, it turns out I only need to change one line of code. A quick look at code/game/g_weapon.c in the source code is enough to make the change.
This is how the BFG firing function code:

void BFG_Fire ( gentity_t *ent ) {
        gentity_t       *m;

        m = fire_bfg (ent, muzzle, forward);
        m->damage *= s_quadFactor;
        m->splashDamage *= s_quadFactor;
}

And this is how the Plasma gun firing function code:

void Weapon_Plasmagun_Fire (gentity_t *ent) {
        gentity_t       *m;

        m = fire_plasma (ent, muzzle, forward);
        m->damage *= s_quadFactor;
        m->splashDamage *= s_quadFactor;

}

Replacing the call to fire_plasma() with a call to fire_bfg() changes the "bullet" coming out from a plasma gun.
However, this is only a quick hack and it only works correctly on arenas which has a real BFG gun. Otherwise the rendering output of the "hacked" plasma gun is incorrect because it only shows swirling black rectangle toward the enemy.
All-in-all it's a nice experience for me :).

Resuming Erratic SVN Checkout

I've just stumbled upon disconnected SVN checkout session in a 3G connection. The whole repository that I was working with is more than 200 MB. Now, what to do? It turns out, you can "resume" the SVN checkout session. Simply cd to the root directory of your incomplete local copy of the repository, carry out an "SVN cleanup" and the proceed "SVN update" to resume the checkout. As simple as that. This is a sample broken session:

darmawan@darkstar:~/tmp$ svn co https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2 --username guest

.. disconnected bla..bla..bla..

To resume the session, I do this:

darmawan@darkstar:~/tmp$ cd edk2
darmawan@darkstar:~/tmp/edk2$ svn cleanup
darmawan@darkstar:~/tmp/edk2$ svn up

That's it. If you experience another hiccups, simply "svn cleanup" and "svn update" again. If your connection is very unreliable, you can create a script to automate the process.

Porting Linux Kernel 2.6 to Lexra 5820 Platform

I've been playing around with my wireless access point based-on RTL8186 SoC over the weekend and found probably I could try porting Linux kernel 2.6 into it. It has a Lexra 5820 CPU core which lacks the unaligned memory access instructions found on MIPS. Well, this is just a preliminary and spare time work because it has been running really well with kernel 2.4.18. I just couldn't resist the temptation to try porting kernel 2.6 into it. Well, maybe it's not going to be a time well spent but I believe the experience in doing so will be useful in the future.

Anyway, the lack of the unaligned memory access instructions made me had to work with the unaligned memory handling routine in the kernel source (arch/mips/kernel/unaligned.c) and the memcpy implementation files in the kernel source (arch/mips/lib/memcpy*).

The trick to emulate the unaligned memory access instructions (lwl, lwr, swl, swr) is to turn the routines which use them into byte-wise memory access routines. It's important to note that lwl, lwr, swl, swr instructions operate on word (4-byte) unaligned operands.

Intel Atom x86-64 support

Several Intel Atom models support x86-64 architecture, such as the D400 and D500 series. Upon closer inspection, these models support "only" 36-bits physical address, which translates to 64GB. To me, this seems like the PAE mechanism supported by x86 processors since the Pentium Pro era. In contrast, Intel Core i7 (and other Nehalem derivative) as well as AMD Family 10h CPUs(Phenom II, Athlon II, and others in the same generation ) supports 48-bits physical address.

Anyway, a lot of interesting stuffs are in the Intel Atom datasheet volume 2, which can be downloaded from:
http://www.intel.com/products/processor/atom/techdocs.htm