July 8, 2010 -
So I finally jumped into the wonderful world of custom ROM, with my HTC Hero (unbranded German unit).
This phone was very slow and frustrating with the stock 1.5 ROM. I was planning on getting the Nexus One while being in the US in late June, but finally preferred giving the custom ROM option a try. I think I was right, this saved me a couple hundred dollars, and the phone is amazingly fast now.
ALRIGHT : I’M NOT RESPONSIBLE FOR ANY BRICKED PHONE. OK ? GOOD.
I followed this first guide : http://sites.google.com/site/roothtchero/
It may seem complicated and confusing but really, it’s not.
Basically you flash the recovery image with flashrec, something you should only do once. Actually this is the sensitive operation of the whole process. If you mess up there (like pulling the battery while flashing, if you really want to give it a try be quick it takes like 2 seconds for the flash to be complete), the phone officially becomes a paperweight.
You’ll be able to access the recovery mode by pressing the HOME KEY + HANG UP KEY when turning the phone on.
From there, you can do a lot of operations on your phone.
Nandroid backup will backup the phone as is, including the OS, radio firmware, apps and settings. Everything will be stored on the SD card. My first backup (Android 1.5) weighs around 200 MB.
It is highly recommended to backup your phone anytime you want to try a new ROM.
You can also mount the SD card on your computer while in the recovery mode (with the USB-MS option).
You load a custom ROM onto the root of the SD card, you select the “flash/restore” menu, pick up the ROM you want and hit confirm. Actually, I recommend wiping the phone before loading a ROM.
After a few minutes it should say the install is done. You can reboot and enjoy your new ROM.
The process took less than 15 minutes for me.
Talking about the ROM, I went with VillainROM 12.0 ROM (after testing a few others). It is an Android 2.1 custom ROM with Sense. I’ve been using it for a couple of days, it’s very stable and fast. Hardware is working perfectly.
This ROM comes pre-rooted. It already comes with OpenVPN binaries and tun.ko module and aNetShare for Wi-Fi tethering. Neat !
Actually, I only had to install “OpenVPN Settings” from the market to get me going.
You put all your config files, keys, etc. under a folder named “openvpn” on the SD card.
Config files must end with *.ovpn !
In OpenVPN Settings, you’ll have to load the tun modules when OpenVPN starts.
I had to use the insmod method.
Specify the path to the module : /system/lib/modules/tun.ko
Next, you’ll have to grab the Android SDK on your computer.
When it’s done, plug your phone into your computer with the USB cable, and type this as root (assuming your are under Linux or Mac) :
/home/user/android/adb shell
You should have a prompt on your phone now.
Type :
su
bash
You should have a bash prompt now 
Now type the following :
cd /system/xbin/bb
mount -o remount,rw /dev/block/mtdblock3 /system
ln -s ../ifconfig
ln -s ../route
mount -o remount,ro /dev/block/mtdblock3 /system
This is what I had to do because OpenVPN was complaining about ifconfig and route commands. Apparently OpenVPN looks for the binaries under /system/xbin/bb. Those are under /system/xbin/.
I got the explanation from this link : http://www.villainrom.co.uk/viewtopic.php?f=46&t=1888
Exit the shell, unplug the phone from your computer.
If your OpenVPN config is correct you can start OpenVPN Settings.
The current version apparently has a bug.
You have to select “OpenVPN”, then select the OpenVPN configuration you want to load.
You expect it to work but it won’t, you have to deselect OpenVPN and select again, from there it will load the configuration, eventually prompting your for your password or whatever, and finally connect you.
Last thing I’d like to mention : screenshots on Android
As root, you can take screenshots, look it up on the market, there are a dozen applications doing that.
If you have any questions, concerns or comments, feel free to drop a line in the comments
November 13, 2008 -
I’m under Debian Lenny at work.
I installed the VPNC plugin (Cisco VPN) for NetworkManager today.
I usually always connect to OpenVPN tunnels with the OpenVPN plugin, which works pretty well (at least on NM 0.6.6).
After installing the VPNC plugin, I started having issues with my OpenVPN tunnels.. I was not able to resolve remote hostnames correctly.
The problem was that my resolv.conf didn’t get updated upon connection to the OpenVPN.
When installing network-manager-vpnc-gnome, a dependency named “resolvconf” got installed along. The package somewhat protected /etc/resolv.conf from being updated.
After getting rid of resolvconf, my OpenVPN VPNs are working again !
Also, this didn’t prevent the Cisco VPN from working..
I need to check out what that resolvconf package is all about.. if someone has a clue, please comment
July 18, 2008 -
I’m really into OpenVPN these days, see my two previous posts about it :
Setting up OpenVPN for your road warriors :
http://www.wains.be/index.php/2008/07/15/a-vpn-for-remote-users-with-openvpn/
Setting up a VPN between two sites :
http://www.wains.be/index.php/2008/06/07/routed-openvpn-between-two-subnets-behind-nat-gateways/
Today : how to route all traffic through the OpenVPN tunnel
On the server side :
First of all, if you want to route all your traffic through the VPN tunnel, you need to turn on IP forwarding (also called routing) and add a masquerading rule on the server (where eth0 is the device connecting you to the internet) :
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.30.0.0/24 -o eth0 -j MASQUERADE
To make routing persistent, see http://www.wains.be/index.php/2006/06/06/enable-ip-forward-under-rhelcentos/
Then, here’s the OpenVPN configuration :
port 10000
proto udp
dev tun
comp-lzo
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
duplicate-cn
server 10.30.0.0 255.255.255.0
client-to-client
push "dhcp-option DOMAIN local.example.org"
push "dhcp-option DNS 172.16.7.253"
push "redirect-gateway def1"
keepalive 10 120
persist-key
persist-tun
user nobody
group nogroup
log vpn.log
verb 1
chroot /tmp
You can see the option redirect-gateway that is responsible for creating all the routes on the client computer when the connection is set up.
The two other push options are only taken into account by Windows clients (to my knowledge).
If you want to change the DNS resolution of your linux clients, you need to use the up and down options on the client (see below).
Client configuration :
vpn.conf :
client
dev tun
proto udp
remote vpn.example.org
port 10000
nobind
persist-key
persist-tun
ca ./ca.crt
cert ./user.crt
key ./user.key
verb 5
up ./up.sh
down ./down.sh
ping 60
ping-restart 120
up.sh :
#!/bin/sh
mv /etc/resolv.conf /etc/resolv.conf.bak
echo "search local.example.org" > /etc/resolv.conf
echo "nameserver 172.16.7.253" >> /etc/resolv.conf
down.sh :
#!/bin/sh
mv /etc/resolv.conf.bak /etc/resolv.conf
When connecting to the server (with verbose option set to 5), we can see the server pushing the route settings to the client.
Fri Jul 18 23:22:19 2008 us=838005 ifconfig tun0 10.30.0.6 pointopoint 10.30.0.5 mtu 1500
Fri Jul 18 23:22:19 2008 us=843211 route add -net 72.x.x.x netmask 255.255.255.255 gw 172.16.7.253
Fri Jul 18 23:22:19 2008 us=845178 route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.30.0.5
Fri Jul 18 23:22:19 2008 us=848568 route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.30.0.5
Fri Jul 18 23:22:19 2008 us=850460 route add -net 10.30.0.0 netmask 255.255.255.0 gw 10.30.0.5
On the client, the routes :
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
72.x.x.x 172.16.7.253 255.255.255.255 UGH 0 0 0 wlan0
10.30.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.16.7.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.30.0.0 10.30.0.5 255.255.255.0 UG 0 0 0 tun0
0.0.0.0 10.30.0.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.30.0.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 172.16.7.253 0.0.0.0 UG 0 0 0 wlan0
July 15, 2008 -
This article quickly explains how to set up a VPN for your remote users based on OpenVPN in around 5 minutes.
If you want detailed informations about OpenVPN, certificates or other stuff, this is not the right place.
This applies to Debian Etch but will work will little difference in paths under Red Hat.
On the server
Install OpenVPN and the dependencies :
# apt-get install openvpn
Copy the scripts that will help us generate all the necessary files (certificates, keys, etc.) :
Under Debian :
# cp -aR /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/pki
Under RedHat :
# cp -aR /usr/share/doc/openvpn-2.0.9/easy-rsa/2.0 /etc/openvpn/pki
Let’s start :
# cd /etc/openvpn/pki
Edit the variables :
# vim vars
export KEY_COUNTRY=US
export KEY_PROVINCE=SC
export KEY_CITY=GREENVILLE
export KEY_ORG=”Green Company, LLC”
export KEY_EMAIL=”admin@example.org”
Set the scripts executable :
# chmod +x *
Source the variables :
# . ./vars
Set up the keys environment :
# ./clean-all
Build the certificate authority (CA) :
# ./build-ca
Build the certificate and private key for the server :
# ./build-key-server server
It’s not necessary to set a password.
Then, build the Diffie Hellman file :
# ./build-dh
Build the client certificate for your first user :
# ./build-key-pass client1
You’ll be asked questions about the client.
Now under /etc/openvpn/pki/keys you must find a bunch of files.
Copy the files necessary for the server on the server under /etc/openvpn :
ca.crt
server.crt
server.key
dh1024.pem
Do so with a single command :
# cp /etc/openvpn/pki/keys/{server.crt,server.key,dh1024.pem,ca.crt} /etc/openvpn
Send the following files to the client, store them wherever pleases you :
ca.crt
client1.crt
client1.key
Send the following configuration to the user “client1″ (vpn.conf which would reside in the same directory as the certificates and key) :
remote vpn.example.org
port 10000
proto udp
dev tun
comp-lzo
client
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
verb 3
ca ./ca.crt
cert ./client1.crt
key ./client1.key
route 172.30.0.0 255.255.0.0
#up ./up.sh
#down ./down.sh
ping 10
ping-restart 60
The up and down scripts are respectively executed when the connection is opened and closed.
You can for example change the name server the client will use when connected to the VPN using those scripts (or opening ports in the firewall, etc.).
Server (/etc/openvpn/vpn.conf on the server) :
port 10000
proto udp
dev-type tun
dev vpn-user
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
# enable compression
comp-lzo
# allow several users to connect with the same certificate
duplicate-cn
server 10.30.0.0 255.255.255.0
client-to-client
keepalive 10 120
push "dhcp-option DOMAIN local.example.org"
push "dhcp-option DNS 172.30.0.254"
persist-key
persist-tun
user nobody
group nogroup
log vpn.log
verb 1
The server will “push” the DNS settings to the client, this will modify your /etc/
resolv.conf so you will use the DNS server and hostname resolution of your office (or whatever place you are connecting to) when connected to the VPN.
On the server, make sure openvpn starts at boot by uncommenting the following line under /etc/default/openvpn (Debian) :
AUTOSTART="all"
When done, restart OpenVPN on the server :
# /etc/init.d/openvpn restart
Now, connect from the client (as root, or use sudo) from a remote network :
# openvpn --config vpn.conf
The client will get an IP in the range 10.30.0.x on the device tun0, it will add a route to the range 172.30.0.0/16 through the VPN (172.30.x.x in this example is supposed to be the network subnet on the server side).
June 7, 2008 -
Edit : between two or MORE subnets. Check out the exchange between Michael Antal and me in the comments. He’s been able to interconnect 3 subnets using this method and some slight tweaks in routes.
The following is the configuration needed to create a routed OpenVPN network between two remote subnets, both behind NAT gateways. On each side, the gateways will act as the VPN gateways.
Network subnets on both side must be different. In this example, we connect 192.168.1.0/24 to 192.168.200.0/24.
With this setup, we don’t even need to open ports at the NAT level on either side of the VPN.
Network configuration
Network A :
Subnet : 192.168.1.0/24
Gateway for Network A
VPN interface (tun0) : 10.0.0.1
Eth0 : 192.168.1.254
Eth1 / Public IP : 212.x.x.x (machineA.example.org)
Network B :
Subnet : 192.168.200.0/24
Gateway for Network B
VPN interface (tun0) : 10.0.0.2
Eth0 / Public IP : 66.x.x.x (machineB.example.org)
Eth1 : 192.168.200.254
If we imagine forwarding is rejected at the firewall level on machine B, we would need to allow traffic between the tun device created by OpenVPN and the LAN interface, as root you would then type :
iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
Make sure the rules remain applied across reboots (using iptables-save or storing the rules in /etc/rc.local or else)
Enabling IP routing :
We need to enable routing on both VPN gateways..
echo “1″ > /proc/sys/net/ipv4/ip_forward
Using this method, routing is not persistent across reboots, check the following link :
http://www.wains.be/index.php/2006/06/06/enable-ip-forward-under-rhelcentos/ (which works for Debian as well)
Static key generation :
We will use simple static key for our example…
openvpn --genkey --secret /etc/openvpn/vpn.key
Share the key between the VPN gateways over a secure channel (scp, etc.).
If you want to use certificates instead (which I recommend), check out : http://www.wains.be/index.php/2008/07/15/a-vpn-for-remote-users-with-openvpn/
OpenVPN configuration :
machine A : /etc/openvpn/vpn.conf
remote machineB.example.org
float
port 8000
dev tun
ifconfig 10.0.0.1 10.0.0.2
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
secret /etc/openvpn/vpn.key
route 192.168.200.0 255.255.255.0
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1
machine B : /etc/openvpn/vpn.conf
remote machineA.example.org
float
port 8000
dev tun
ifconfig 10.0.0.2 10.0.0.1
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
secret /etc/openvpn/vpn.key
route 192.168.1.0 255.255.255.0
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1
Establishing the connection :
On machine A type :
openvpn --config /etc/openvpn/vpn.conf
Machine A will try to establish the connection. Type the same command on machine B to initialize the connection.
As soon as the connection is up, hosts on network A should be able to ping hosts on network B and vice-versa. If you can’t ping from one side to the other, it’s probably a routing issue.
We can use traceroute from a machine on network A to see the path taken to reach a host on network B :
$ traceroute 192.168.200.30
traceroute to 192.168.200.30 (192.168.200.30), 30 hops max, 40 byte packets
1 192.168.1.254 (192.168.1.254) 2.128 ms 2.378 ms 2.781 ms
2 10.0.0.2 (10.0.0.2) 132.761 ms 137.342 ms 141.130 ms
3 192.168.200.30 (192.168.200.30) 136.752 ms 133.869 ms 135.960 ms
We can see the traffic is going through the 10.0.0.2 interface.
We also can check the routing table on the VPN gateway on network A :
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.200.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
0.0.0.0 212.x.x.x 0.0.0.0 UG 0 0 0 eth1
We see any traffic directed to 192.168.200.0/255.255.255.0 must go through interface 10.0.0.2 on device tun0.
Making sure the VPN connection is established at boot (Debian way) :
Edit /etc/defaults/openvpn and specify which VPN network must be started.
Make OpenVPN starts at boot with this command :
update-rc.d openvpn defaults
OpenVPN will start any VPN configuration named *.conf found in /etc/openvpn/
So don’t store copies of config like test.conf test-backup.conf as OpenVPN will try to start them at boot.
October 8, 2006 -
I’ll explain how I used a static key configuration to get a simple VPN tunnel to connect to my samba share at home from work.
May 24, 2006 -
This will explain how to setup a simple OpenVPN tunnel between two computers (at a time). If someone attempts to connect while another person is already connected, that person will get bounced from the VPN tunnel..
