The telephone number you have to set is *99#, which should be provider-independent.

The following settings are for yesss.at only:
Username: web
Passwort: web

Remember to set the APN as part of the driver’s connection string in Window’s “Device Manager” as described in the PDF.

Again, for yesss.at this is: AT+CGDCONT=1,"IP","web.yesss.at"

For this to work properly, the SIM must not have a PIN set, as otherwise the SIM will be locked and the dialer cannot dial out. For me this is ok, as it is a pre-paid card which can hardly be abused if it gets stolen, but your situation might be different, so please consider the security implications. (I suspect that it should be possible to unlock the SIM card somehow using the AT+CPIN=1234 command, but I did not research how to separate several initialization strings, as it did not work immediately.)

The solution works quite well for me, even under Windows 7. Disadvantage is that there is no way to tell the signal strength and exact mode of operation (despite the color-coded status led on the Merlin U740).

(Note: this is a rather advisory level HOWTO, not a step-by-step, command-by-command tutorial. It might give you some ideas nevertheless.)

This version of my synchronization solution is based on a central dedicated server on which you can install Unison and login via SSH using public key authentication. You can also do the same with an external media, like an USB-Stick, but there you could use the external media directly without syncing. I would recommend using synching even in this case, as Flash-based media like most USB memory sticks only have limited write cycles. Additionally, if you use synching, you get some redundancy (I wouldn’t go as far as call it “backup”) in case one of your storage devices fails.

Step 1 – Preparation

Unison is one of my favorite two-way synchronization tools. It works by keeping a database for every replica, so it can detect new, modified, and deleted files. The program was originally target at Linux, but there is a client for Windows as well, which works well. Its major advantage in my opinion is that it uses the rsync-protocol for transferring the data, which keeps the ordinary synchronization bandwidth reasonably small.

You have to install Unison on every client that is going to participate. Important: you need to install the same version for every peer!

Step 2 – The Central Hub

Then you need the central server. I am using a Gentoo-based dedicates server at Hetzner. You don’t need a real server, but it must be an “always-on”, always reachable computer. It could be your gateway at home, but keep in mind you need to contact the host. Consider using DynDNS or similar services if you don’t have a static IP for the box. The server can even be one of the target computers, but as mentioned, it needs to be reachable via the Internet for the other sync-partners.

I created a dm_crypt encrypted partition of 1GB size and mounted it at /home/martin/shared. The 1GB size is enough for me, in fact, the shared data is around 100MB. I am sharing data, not programs or (large) multimedia files.

Step 3 – Configuring a Linux Peer

Configuration of a Linux peer is the easier than configuration of a Windows peer, that’s why I am starting with this. First you need to create a SSH-key which will be used for authentication if you don’t already have one. Unison needs to be able to login via SSH without user interaction, still I do not recommend to create a key without passphrase. Protect the key with a passphrase, but use something like keychain to authenticate only once against the key before starting your synchronization.

You need to add the key to the ~/.ssh/authorized_keys2 file at the central hub. Ensure you can now login as the desired user using ssh without a password prompt.

Once SSH is working, you can create a profile for unsion, like my shared.prf:

root = /home/martin
root = ssh://martin@<server>//home/martin
path = shared
ignore = Path {shared/local}

This profile synchronizes the ~/shared/ directory to the central hub’s ~/shared/ directory, ignoring anything at ~/shared/local, which gives you the easy possibility to exclude some of your files from synchronization.

That’s it, you can now synchronize the Linux host to the central hub. Do this anytime you quit working with the computer to prevent conflicts due to concurrent modifications on different workstations.

Step 4 – Configuring a Windows Peer

Windows configuration is a little bit different (but not much). First I create a TrueCrypt volume of the desired size. I like to have all shared folders at the same location, just out of habit. So I mount them all at S:\ and create a #shared subdirectory, which is going to contain the shared files. (Using TrueCrypt is entirely optional and not required, I just want to make it thieves a little bit harder to read my personal data.)

Then you need to have PuTTY (including plink and (advisable) pageant). Create a key and add it to the central hub’s ~/.ssh/authorized_keys2 files. I again advise against keys without password. Use pageant to cache the credentials for synchronization.

The Unison profile needs to be different for Windows, as you need to convince Unison to use PuTTY instead of ssh. Therefore a small batch-script is required, I call it launcher_server.cmd (containing just one line, remove the word wrap):

@"C:\Program Files\PuTTY\plink.exe" -i "S:\putty-key.ppk" martin@my.server.domain unison -server

Make sure the connection is able to login without further authentication.

The shared.prf needs to be a little bit different here:

root = S:/#shared
root = ssh://martin@<server>//home/martin
sshcmd = S:/Program Files/Unison/launcher_server.cmd
fastcheck = true
path = shared
ignore = Path {shared/local}

(Note: the “fastcheck” attribute is optional, but I recommend using it on Windows, but see the Unison documentation for further infos before using it!)

Step 5 – Synchronize

After you have set up all the hosts you want to participate, simply use it. Use keychain and pageant to ensure you don’t need a password for login at the central hub. You should synchronize whenever you log off or shut down a workstation, to ensure there will be as little conflicts as possible. As long as you don’t create conflicts, even concurrent modifications can be handled automatically.

And now, have fun and enjoy working with a consistent dataset over multiple computers.

I though faced one problem: I could not get phpMyAdmin working and this was a requirement of one of my clients. phpMyAdmin kept popping up the authentication dialog over and over again when using HTTP Basic Authentication.

After searching some time, I noticed that, when using PHP in CGI mode, the authentication data is not passed over to the script by default. A FAQ entry of phpMyAdmin brought the solution to this issue: a ReWrite Rule was needed for the directory containing phpMyAdmin:

RewriteEngine On
RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L]

Suddenly phpMyAdmin worked

As described in this VMware Knowledge Base Article, you can turn of VMWare’s behaviour to use a memory mapped file and force it to use the system’s paging mechanism instead. To do so, you just have to add

mainMem.useNamedFile=FALSE

to your virtual machine’s configuration file (.vmx).


RewriteEngine On
RewriteCond %{SERVER_PORT} !443
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]