First and foremost, human relations are way more complicated than just a connection between two profiles on a social networking site and this is something we conveniently forget most of the time: family, neighbours, acquaintances, colleagues, friends and girlfriends are totally different groups, possibly overlapping and constantly changing, but each with a distinct set of information that you want to share and rules for doing so, informal as they may be. On Facebook, whatever you write in your status message and profile is visible by all your contacts regardless of their relation to you, with the obvious consequence that you have to write rather bland tidbits for the most distant group, i.e. neighbours and acquaintances, if you wish to play safe or risk exposing sensitive information if your target group is friends and colleagues. Not cool.

Sometimes my reply is that I already am an expert at wasting my time and don’t need another way of doing that. Though it is delivered with a smile, this answer has a deeper meaning: I already have LinkedIn for professional connections and CouchSurfing for traveling and meeting new people; keeping them up to date requires time and I have no wish for yet another social network site to maintain. I prefer to use that time for meeting actual people, as opposed to just reading their profiles, or for my hobbies.

Another underestimated issue is privacy, or lack of, in Facebook: without even getting into the conspiracy theories surrounding it, at least I’d like to try and keep my private data to myself, as much as possible. Usually, when I raise this point, the other party suggests that I create a profile with a pseudonym, which is naive for at least a couple of reasons: for starters if I were to use a service like this I’d want to use my real name to maximise its networking potential but, most importantly, we already know that anonymous data isn’t.

So, for the time being, no Facebook account for me. Thank you for your time.

The good news? Using Upstart is the correct approach and obviously works perfectly as far as the data connection is concerned.

The bad news? Apparently, there’s some weird interaction going on with tethering and the phone data counter:  the traffic caused by the attached computer is not added to Settings->Phone->Data counter, which is simply overwritten. According to the dataplan monitor applet, before tethering I had used 24MB out of my monthly quota of 3GB but when the connection ended the counter was reading 2MB instead of 26MB. The reset date for the counter was unchanged, though, so I’m inclined to think this is not the intended result.

Bottom line: if you rely on the applet to monitor your quota usage and wish to use tethering, be aware that you need an alternate way to check your situation, such as 3 Wired Portal

EDIT: apparently the data counter is clobbered also when using DUN over USB

As a wannabe developer, the experience with Maemo 4 (Diablo) was great and it looks like it will get even better with Maemo 5 (Fremantle): coming up now is the Maemo Barcelona Long Weekend, a 3 day event where developers will meet UX specialists to further improve the usability of the interfaces.

Unfortunately I won’t be able to attend (can’t take enough days off my day job) so when qgil mentioned the mere possibility of a similar event in Italy I jumped at the chance and started organising it!

You’re welcome to join the discussion on talk.maemo.org and also to spread the word to as many Linux developers as you can: we need mindshare, we need ideas, we need locations and dates. Oh, well, at least we have an idea of possible dates but everything is still very fluid so, please, do give your contribution.

We spent a nice hour or so chatting together and demonstrating the capabilities of the Nokia N900 and even took some pictures of the event. What made it particularly funny in my opinion was the location and the white/black contrast of the products on display and our N900’s. Maemo über alles!

So, here are the pictures!

N900 box in a fruity store

Rodrigo and me

N900 and a white fruity mouse

Guys, be patient: this beauty will soon hit the stores!

First, the obligatory background information: I am running a self-compiled OpenWRT at revision 15252 on an Asus WL-500gP v1; because of the v1’s Broadcom card, I temporarily stopped tracking SVN as recent builds won’t work, pending a driver change, hence the ancient revision. Then, I wanted to use the nonstandard port 53 for the VPN since it has a better chance to be unfiltered at most locations than any other port: I’ll explain the acrobatics involved in keeping OpenVPN and DnsMasq off each other’s throat later on.

Configuration

UCI stores settings for OpenVPN in /etc/config/openvpn: this file has multiple stanzas, one for each VPN configuration; there are two sample configs (server and client) and a hook for adding a customized external config file, which we won’t use. Instead we’ll add a new stanza, right under the “Package” keyword:

config openvpn <newvpnname>
option enable 1
option ca /etc/openvpn/ca.crt
option cert /etc/openvpn/server.crt
option comp_lzo 1
option dev tun
option dh /etc/openvpn/dh1024.pem
option ifconfig_pool_persist /tmp/ipp.txt
option keepalive "10 120"
option key /etc/openvpn/server.key
option local a.b.c.d
option max_clients 5
option mtu_test 1
option persist_key 1
option persist_tun 1
option port 53
option proto udp
list push "dhcp-option DNS 10.13.37.1"
option script_security 2
option server "10.13.37.0 255.255.255.0"
option status /tmp/openvpn-status.log
option topology subnet
option up /etc/openvpn/vpn-fw-helper.sh
option user nobody
option verb 3

Looks simple enough, right? Let’s take a closer look anyway:

• the <newvpnname> parameter is used by UCI to identify different subsections of the config and by syslog to label messages: pick a reasonable name, just take care not to use an existing name like sample_server and so on!
• the enable option is the master switch for our new configuration stanza: by toggling it, we can enable&disable our section using UCI’s commandline tool.
• there is no default path in UCI so all key and cert files must use a full pathname
• local: ip address for the vpn server, normally not needed when the wan port has a dynamic addresss; it is required in this setup because of the port choice

Port 53 gotchas

Reading about a vpn running on port 53 should send a shiver down your spine, since you remember another slightly more common service already using that same port: the DNS!

Dnsmasq

No worries, we’ll just tell dnsmasq to bind the lan interface and openvpn to bind the wan side. Easy? Not quite: for starters, having dnsmasq bind only br-lan means not being able to provide a dns server on the vpn link. No, you can’t just run another instance of dnsmasq, because it will insist in binding localhost in addition to the vpn interface and localhost:53 is already taken by… right, dnsmasq for the br-lan segment. Sounds like a game of Mikado, heh?

Now, edit /etc/config/dhcp either directly or through the nice  LUCI web interface and add:

option 'interfaces' 'br-lan'

or whatever the name of your lan segment is, then reload dnsmasq.

One last step: we need to restart dnsmasq when the vpn is started, to add its interface to the commandline. This is achieved through the “up” hook and a helper script, that uses the uci_set_state function so that the change is not retained across reboots.

OpenVPN

The “port” keyword in the config forces us to enter a local IP address for the OpenVPN server but this information will be different each time the WAN connection is started. Solution is to disable autostarting of the vpn and use hotplug to dynamically reconfigure and restart openvpn when the WAN connection is estabilished. 30-openvpn should be placed under /etc/hotplug.d/iface and will add the “local” keyword together with the address to the configuration. It is a rather crude hack, as it does not yet check whether the old config had the keyword or not but it works for me.

Final notes

I have tested this configuration with the current clients on Kubuntu 9.04, N810 and Windows XP. Of course, the connecting clients will need some kind of dynamic dns service to locate the server. It works but there is clearly room for improvement: for example, the helper script will not be run again if the firewall configuration is reloaded so forwarding will be lost. I have yet to figure out the cleanest way to configure the firewall so that no more rules are added than strictly necessary.

EDIT: of course, after getting a N900 and testing the vpn over the UMTS connection, I had to change the port from 53 to 443…. serves me right!

The newer version will hit the Extras repository as soon as possible. For the time being, here is the version I built on my sdk.

More specifically, this is supposed to backup all of /etc/openvpn:

<backup-configuration>
 <locations>
   <location type="dir" category="settings">/etc/openvpn</location>
 </locations>
</backup-configuration>

instead of leaving out the key file, forcing me to regenerate it. No, the file was not even saved while the following files were saved but not restored:

/etc/osso-backup/my-custom-backup.conf
/etc/hostname, hosts
/etc/systemui/systemui.xml

Something fishy is going on… will investigate.

EDIT: backup is missing those files which are not readable by user.