How to use SSH for an Internet Connection Sharing Proxy

I haven't made a blog in a long while, so I'd thought I'd share this, which I recently discovered how to do.

If you find the idea of proxies a bit restrictive. because after all, they have to be set up in the applications in question, and may not work for some applications, help is here. And all you need is an SSH server you can connect to. Sadly, this method requires root, but it's worth having for the system-wide Internet connection you'll get from it.

Authenticating as root

First, make sure you're root on the client machine (sudo -s or su -, depending on your distro), and that you can ssh as root to your target server. This is of course causes security implications, so it may be a good idea to generate a key pair for root-to-root access and block off passworded access for root, so that no one can bruteforce your root password.

Generate the key pair as root on the client:

client:~# ssh-keygen

And copy the key to the server

client:~# ssh-copy-id [server]

Test the root login. It should not prompt you for password authentication (unless you've set one in ssh-keygen). Now, to block off password logins, edit /etc/ssh/sshd_config (or /etc/sshd/sshd_config) on the server and make sure this line is present:

PermitRootLogin without-password

Hooray! We're now somewhat more secure!

Creating the tunnel

Now to start a tunnel. The -w switch on ssh will do what we need, and create a tunnel network interface on both computers. The first number is the number of the interface on the client, and the second is for the server. For example, 0:! will create tun0 on the client connected to tun1 on the server. You may specify auto for the next available one. Let's create tunnels called tun0 to make it simpler.

client:~# ssh -w0:0 [server]

Now, see if your tunnels were set up correctly.

server:~# ifconfig -a tun0

You should see a tun0 interface. This is a layer 3 tunneled virtual interface (point-to-point).

Set up an IP on both sides so each computer can talk to each other.

server:~# ifconfig tun0 pointopoint
client:~# ifconfig tun0 pointopoint

Try pinging each side to see if you have a connection.

Once each host can talk to the other, we can set up the routing.

Setting up the routing

Server setup

Ensure that the tun0 interface is not restricted:

server:~# iptables -A INPUT -i tun0 -j ACCEPT
server:~# iptables -A OUTPUT -o tun0 -j ACCEPT
server:~# iptables -A FORWARD -i tun0 -j ACCEPT

Allow packets in from the external interface to be processed by the tunnel:

server:~# iptables -A INPUT -i eth0 -d -j ACCEPT

Allow forwarded packets to be routed to their destination:

server:~# iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

Set up tun0 for NAT:

server:~# iptables -A POSTROUTING -o tun0 -t nat -j MASQUERADE

Enable IP forwarding in the kernel:

server:~# echo 1 > /proc/sys/net/ipv4/ip_forward

Client setup

Allow packets to be processed from the tun0 interface:

client:~# iptables -A INPUT -i tun0 -j ACCEPT
client:~# iptables -A OUTPUT -o tun0 -j ACCEPT
client:~# iptables -A FORWARD -i tun0 -j ACCEPT

Setting up the gateways

Find the existing default gateway:

client:~# route | grep ^default

Add a backbone to stop the server not being found once we switch gateways:

client:~# route add [server IP] gw [existing default gateway]

Add the new default gateway:

client:~# route add default gw

Remove the existing default gateway (Be very careful!):

client:~# route del default gw [existing default gateway]

Testing the tunnel

Try going to whatismyip.com in your browser. It should show you the IP of your server. If you're curious, you can also check the default route to somewhere like Google by using the traceroute utility.

You're done!


I can't see a tun0 interface!

Make sure you're root on both sides. (It sounds obvious - I've thumped my head on my desk so much because of this!)

Start ssh with the -v switch to show more verbosity. If you see a message a bit like this:

debug1: Remote: Failed to open the tunnel device.
channel 0: open failed: administratively prohibited: open failed

it could mean that someone else is trying to create a tunnel with the same interface name on the server.

If you see something a little like this:

debug1: sys_tun_open: failed to configure tunnel (mode 1): Device or resource busy

it might mean that you already have a tunnel with that interface name open. Check "ifconfig -a".

I get the message "ping: sendmsg: Operation not permitted" when testing the tunnel connection!

You didn't allow traffic to flow between the tunnel and local network device. Try turning the client firewall off.

The connection is slow!

There will be significant overhead as all the traffic is encapsulated into SSH and encrypted. You will also see latencies go up as traffic needs to travel from your client to your server and back additionally.


Rules of Mobile Platform Development

A lot of things annoy me about mobiles. Here are some handy tips to you carriers, manufacturers, OS and app developers to make sure you do it right.

1) The User always comes first
Research what you think your users would like. Try not to blindly irritate users, and do what they want, don't force things upon them. Don't autostart without user permission, do things properly so that they're faster, and ask for feedback on what the application should and shouldn't do. Don't pop this up, let the user choose it from your easy menu. And finally never pester, or you'll drive your users away.

2) Don't advertise
Wasting a few pixels on a desktop isn't going to make a whole lot of difference, but on a mobile, it can severely break layouts. It can also waste people's precious bandwidth - after all, they paid for their little Internet space - and only want what they ask for. It also doesn't help your cause - after all, you don't want to drive your users AWAY from your app, do you? Advertising on a phone can be intrusive and annoying, too. Don't do it.

3) Try not to use menus
This in my opinion is something Apple did right with their iPhone, and Google did wrong with Android. Menus inside apps (especially on mobiles) tend to get confusing, and sometimes (e.g. if the menu button is a software button) get pressed accidentally.

4) Speed
An obvious one. Try to make your platform as fast as humanly possible - do everything you can to make sure each task is as speedy as is possible - that is, index your applications, don't make unnecessary requests, etc. If starting an application takes ten seconds - you're doing it wrong. If searching for a list of installed applications (and so on) takes forty - don't release yet. We've already seen a terrible example of this in Android pre-2.0. The general rule is that if it needs a loading screen, then it's already too slow.

5) Don't pester
I install a free application. The app starts, and it asks if I'd considered its paid version, with this set of features, that amount of extra greatness. That's fine. I consider it. I say no. Besides, now I know it exists, if I change my mind, I can just as easily go and get the paid version. Job done. However, many apps I've previously used (not pointing any fingers) seem to pester me to upgrade. Whether on startup, or on accidental activation of a "pro" feature - it asks me again and again. This is no good!

6) No Demos.
A free application should not be a "demo" of another paid one. I don't have time to waste, and if I want an application, I'll download the free one first. This may contain buttons which correspond to features only in the paid version. But I don't know that of course. They should be disabled and obvious, not look the same and pop up an annoying box saying "DEMO! Upgrade for only $3.99 for this feature". Even better, there should be one button in the menu that describes the different features. If I don't think I have enough, I'll go get the full version. If I think I have enough, and some turn out to be fake, it really bugs me.

7) Just Try Again
I often browse the web on my phone. Sometimes at no notice at all, the connection drops. Of course, the software can't be blamed for this, but the carriers can (unless it's obvious I'm in a place that has no chance of reception, such as in a tunnel). However, what annoys me is that when this happens, I have no "no reception" warning until about 30 seconds after the page doesn't load. I put it away, thinking it'll load eventually, and it never tries again. Trying again sounds like the sensible option to me, because after all, I asked for the web page, and I still want it when it's available again!

8) No Restrictions
There has been much anger towards certain carriers and manufacturers who lock down the operating system unnecessarily, forcing users to resort to things like rooting and custom ROMs to do the things they should have been able to do in the first place (e.g. wireless/wired tethering). A classic example of this would be the Motorola, which locked the bootloader in its Milestone phones, preventing first rooting (this could be enabled by flashing a vulnerable recovery image) and the ability to run custom ROMs with custom kernels, which in effect has had a bad effect on these handsets

9) Use Less Power
The more battery life the user can get out of their device, the better. Manufacturers and app developers need to learn that it is unacceptable for the user's device to run out of batteries half way through the day. So don't start your application or service on bootup - and try to minimise memory usage. Only start when the user wants you to start. I've found that numerous apps and services I don't need yet need to be killed on bootup! All apps should be opt-in bootup - and once you start it, if it makes sense to start on boot (such as a network monitor) then ask as soon as you install.

10) Make It Fun
A lot of apps are just plain boring, and I'm not accusing anyone personally. But it goes without saying that something fun and exciting will be more readily liked and bought by users and rated higher. Spend time making something people of all ages would like (unless it's specific) and would be willing to spend time playing or using.

11) Many Easy Updates
Everything's going to be buggy, so update often once you find a bug. Lots of small updates are better than few large ones - first to rid users of those niggling problems sooner rather than later, and second because it's less to download in a month. To phone manufacturers, don't hang around, and release OS updates as soon as they're available - they may provide valuable security updates. If you can't, let your users do it - move development into the community. The easiest way to update is by Market (for apps) or by OTA (over-the-air) update (OS updates).

12) Don't be Motorola
Ashamefully, Motorola has not been following some of these rules effectively. They almost never update their phones and leave them on early versions of the operating system. They lock their bootloaders and prevent users updating their phones effectively. So don't be like them. If the user bought the phone, it's theirs and should be able to be modified down to the lowest level.

Do you have any more tips or modifications? Use the comments area below. I hope you found this useful!


Bibud Alpha 5.1 released

Bibud, the open source social web desktop released its Alpha 5.1 version today, including many design changes and bigfixes, finally integrating links to git and a bugtracker.

Among the new features to Alpha 5.1 were:

Homepage improvements
Facebook support in Chatroom
Media sharing initial demo support

As always you can find Bibud at http://bibud.com.


Bibud Social Web Desktop Alpha5 Released

The fifth bugfix update to the Bibud web desktop was released yesterday, and includes easier application installations, a better SDK, a clearer layout, better window management and removal of application previews not relevant to the web demo at this time.

If you've not come across Bibud before, it is a desktop and window manager including and designed to contain several web-based applications that work together to make your computer experience easier. It is designed to run on desktop, laptop or netbook computers, and with a low footprint, is designed to work well on the lowest specification computers available.

Bibud is the name of the entire project, but a demo of what the desktop will look like is available to demo on the web at http://bibud.com - later on it will come preinstalled inaide a GNU/Linux distribution enabling computers to connect and share data with each other in an as easy way as possible.

Technologies in use in Bibud are HTML5 for the audio and video elements, AJAX for most of the desktop, and the backends are programmed in PHP and MySQL, enabling any user with the LAMP stack installed (Linux, Apache, MySQL, PHP) to easily download and install the software. The git repository is available on Github.

Currently, the following applications are available to try out:
  • Audio, Video, Pictures (media viewing applications)
  • Chatroom (an irc-esque chatroom)
  • A Blog application
  • Microblog (submit posts to Twitter, identi.ca, status.net, etc)
  • My Files (a file upload manager)
  • Friends (to keep track of contacts)
  • Background (to change desktop wallpaper)
  • User Info (to change user's passwords, etc)
Features just around the corner are:
  • Media sharing
  • Note taking applications
  • Extra goodies
You can try out the alpha 5 prerelease of the desktop by visiting http://bibud.com in your HTML5-compliant web browser.

The Bibud project are looking for volunteers to help with the project, code contributions, artwork, designs, proof-of-concepts and even just ideas are welcome, and may well be accepted into the official project distribution. If you have anything to contribute, please email the project leader at bibud@dandart.co.uk. The Bibud project is licensed under a MIT-style license.


Features I'd like to see in Sauerbraten

I love the game Sauerbraten. But I can think of lots of ways I think it could be improved. I'll of course try to help this happen, and might update this list (and add suggestions!).

1. Proper gravity (including flying objects, perhaps toggle gravity of objects)
2. Fire hurts
3. Gunge/Poison
4. Circles/spheres easy creation
5. Saving of objects/big stuff for later
6. Admin coop AKA Play God - in which only the master can use editmode - great fun for "playing god" and wreaking havoc when no one else can.
7. Heightmaps in multiplayer (H key)
8. Breath (eg you die underwater after a while, like in Quake)
9. More ambient soundtracks, ambient noises.
10. Button triggers (eg you press or shoot something and something happens).
11. Proper doors that open or swing
12. Moving objects (automatic or manual via button/trigger) - eg trains.
13. Large walls of teleport material, for e.g. trains, yourselves.
14. Materials that change to others after a certain time, e.g. noclip slowly to air
15. Door keys
16. Liquid viscosity
17. No glitching when you try to put a hole in a pyramid
18. More human models
19. Gun reloading sequences
20. Auto getmap/sendmap (Getmap when you join, sendmap when someone else joins)
21. Master newmap restriction
22. Grappling hook
23. Item capture - person who captures most items without being killed wins.
24. Marks on walls from chainsaw
25. Flamethrower
26. Gravity gun
27. Physics gun
28. Time/space warping (global/local/gun) (haha)
29. Shield/Disarming field
30. Turrets
31. Vehicles
32. Flammable items/materials (e.g. wood) with degrading.
33. M/F Voices (inc. player), not just "captured" but also "lacerated" etc.
34. Female models?
35. Customisable music
36. Panic mode (Fuzzy/red view when player has too much adrenaline)


Xenon Web Desktop Alpha2 Released

The web desktop Xenon released version Alpha2 today. The release announcement from the website reads:

"Changes from Alpha include many security fixes (including SQL injection), the addition of the Chatroom app,
Pictures app, width autoscaling, new tab launching, easier installation and various visual tweaks.

Please either use the online version, or download to your server. Please help by submitting bugs, patches,
new apps, icons, etc to xenon@dandart.co.uk. Thank you."

Xenon is a web desktop, which means that all your applications, work and settings are stored on the web.
It can be run from any Internet-connected computer by browsing to the Xenon server or from your own server
(in the case that you want a private instance, or want it installed into a netbook in the case where you do
not have Internet connectivity). Eventually syncing support will be brought in which allows you to sync your
settings and files to and from your local instance and the main server. Other features currently available include:

* Audio player (featuring HTML5 Vorbis audio)
* Video player (featuring HTML5 Theora video)
* Picture viewer
* Email (including within Xenon and outgoing email)
* Blog
* Chatroom (Public, open to all on the same instance)
* Notes application
* Friends application for social features
* My Files, to upload various types of file
* Wallpaper switcher

Upcoming features include:

* Settings syncing and importing
* A small footprint netbook/touchbook operating system to run on
* Many others

To try the system out for yourself, you can try the demo or download the software to your server.

Please send patches, icons, ideas, apps, et al to xenon@dandart.co.uk

The project's website is at http://xenon.kevinghadyani.com or a shorter version: http://hackerlanes.com


Linux's Hardware Support

Lately, I've been hearing a lot about "Linux needs to master .... to beat Windows". I'll now show you how that's completely false, and how it already has beaten it, by talking about hardware support.

Linux has been proved to have the best hardware support around - see this interview with Greg KH who's a kernel dev to see in-depth information. Linux had most support for hardware first, including:
* 64 bit
* USB 3.0
* Core i7

And many more.
Conversely, it's easy to install the hardware on Linux. In windows for instance, half the time your hardware doesn't work because you downloaded a dodgy driver, or you have to install it off a CD, or it could even be the case that it bluescreens because the driver hasn't been verified by whoever. Fair enough, that hardly ever happens anymore.

The misconception that a lot of hardware doesn't work on Linux isn't because it doesn't, it does, but because quite often your distribution of choice doesn't ship with the correct userspace tools - e.g. a webcam viewer, a scanning program, an iPod syncer. It's not the actual Linux kernel that's at fault here, it's that the distribution vendors don't include software to manage and access your device. What we need here is a project that either includes everything or says "I see you've inserted a scanner, but you don't have a scanning application. Want me to install one for you?". I have seen openSUSE do this for me before, but Ubuntu sadly lacks this capability, which is the distro that most users allegedly use, so it needs it here.

The fact of the matter is, every piece of hardware I've put into my Linux box has been detected and set up by Linux, but I have had to install a webcam viewer, scanning application and TV viewer. Perhaps it's time for userspace tools to improve themselves and be as good as the kernel.