It’s been a while since I last acquired new gadgets but I think I’ve made up for lost time with my last weeks purchases.

You may remember that I’ve had my eye on the Openmoko phones since early 2007, but in between shifting across the world and starting a new job I never got around to purchasing one of the first versions. The second version, the “Freerunner”, was released in June this year and I placed an order with Pulster, a local distributor, shortly after. The phones have been in hot demand, so I only received my phone last week, a wait of of almost 2 months, and it turned up missing one of the cables that was meant to come with it. Still some distribution kinks to be worked out.

Distribution kinks are the least of Openmoko’s worries at the moment though. As advertised, the phone is definitely not ready for primetime distribution yet. I’ve tried three different software images on it: the original “stable” 2007.2 image, the current “devel” 2008.8 image and the latest completely rebuilt SHR release which is the most promising yet. With the SHR image I’ve been able to send and receive calls and text messages, although the interface is somewhat arcane. I’m most interested in the GPS which looks to be working reasonably well at this stage.

After almost a week with the phone I’m glad I purchased it, and I’m having fun hacking on it, but there is a huge way to go before I’ll be able to use it as my primary phone. So that’s gadget #1.

The second gadget is a new Digital SLR camera. I’ve been thinking about getting back into photography for a while (I last took photos seriously in high school) and when I saw how affordable digital SLRs had become I couldn’t resist. There isn’t much between Canon and Nikon when comparing mid-range SLRs these days, so after about a week of deliberation I decided on the Canon 450D, primarily because most of my workmates also have Canon SLRs!

I only got the camera on Friday, and spent half the weekend playing with the GPS on the phone (I want to set them up so I can geo tag all my photos), so I haven’t had quite as much time to play with it yet. I expect to spend plenty of quality time with it on our holiday in Malta next week. First impressions are favourable, although I’m fast discovering camera viewfinders were not really designed for people who wear glasses. I may have to consider wearing contacts again.

Once we get back from Malta I’d like to find a local (or online) photography club with some good weekly assignments to fire my creativity and motivate me to get the most out of my new toy.

On hardy after the latest round of updates:


matt@krypton:~$ dpkg -s flashplugin-nonfree | grep Version
Version: 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2


Granted this package is in hardy-backports not hardy proper, but still, what on earth?!?!

I highly recommend making some time to read the The Australian Open Source Industry & Community Report. Based on a census of the Australian Open Source community conducted at the end of last year, it presents a range statistics about the state of the Open Source community and industry in Australia.

The report seems to be aimed at demonstrating to Government and Businesses that Open Source has become a very viable business strategy in Australia and in particular how increased adoption of Open Source would reduce the Australian trade deficit. You don’t need to worry about being put to sleep. The report is relatively casual in tone and easy to read with lots of bright graphs to present the key statistics and findings. Including:

• The Australian Open Source industry generates around AUD$500M in annual revenue. A small proportion of the AUD$54.4B total revenue for the Australian ICT Industry in 2004-2005. Lots of growth potential!
• 70-80% of the industry is based on the traditional development, customisation, support and maintenance business model.
• Most of the individuals making up the Australian Open Source community are working professionals, over half the community are in a relationship and a third of the community have children.

It would be fascinating to see a similar study of the New Zealand industry. I suspect that we would find that Open Source businesses are spread across the country similar to Australia. Obviously our community and financial figures would be smaller in absolute terms but would our proportion of Open Source based businesses be similar?

Maybe a good task for the current NZOSS committee would be to round up some of the larger Open Source businesses in New Zealand, along with the Ministry of Economic Development to sponsor a similar study for New Zealand!

I (as root) have a directory hierarchy that I want a particular group to always have write access to. The files and folders inside the hierarchy are owned and manipulated by a wide variety of diffrent users.

Essentially I want to delegate ‘root’ access for a portion of the filesystem to a particular group.

My first attempt at implementing this was to use the standard POSIX ACLs that are available for almost every filesystem Linux supports.

I recursively set an ACL on the top-level directory to give the group write access to all files and directories that currently exist and then I recursively set a default ACL to give the group write access on all the directories. This default ACL should be inherited by any new files that are created ensuring that the group keeps write access to everything.

Problem solved? Unfortunately not.

The intricacies of complying with POSIX means that ACLs are implemented as an ACL plus a mask. To gain access to a particular file or directory the user or group must match an appropriate ACL granting the access and the mask for that file or directory must also allow the requested permission to be granted.

When you add an ACL to a file or directory, the ‘group’ bits of the standard Unix permissions magically switch from controlling group access to controlling the mask portion of the ACL, effectively providing an upper bound on the permissions that an ACL entry can grant. This prevents legacy POSIX applications that do not understand ACLs from unintentionally granting excessive permissions - arguably a good thing.

Unfortunately this also makes it very hard to preserve the ACL granting write access to the ‘root’ group which I legitimately intended to have in place on this portion of the filesystem.

Newly created files under the hierarchy generally inherit the ACL as intended, as most applications attempt to create files with as many permissions as possible, leaving it up to the umask to remove undesired permissions.

However any file that is copied into the hierarchy without the ‘group’ write bit set, or any file that has the ‘group’ write bit removed via chmod will actually remove the write bit from the ACL mask invalidating the ACL and leaving me back at square one!

After a bit of Googling I thought that NFSv4 ACLs might be the answer to this problem, as they are marketed as “very similar to Windows ACLs” and I’m sure that I vaugely recall Windows being able to properly inherit ACLs from parent directories. Unfortunately after downloading the NFSv4 ACL patches and trying all the various mount options I cannot find any combination that will offer the functionality I need. The implementation conforms to POSIX, so it still has a mask parameter and the same problems as the standard POSIX ACLs. The only benefit from using NFSv4 ACLs that I can see is that you have more permissions to grant.

So once again, I’m back to square one. I’m hoping that there is some fundamental point that I’m missing as this seems like a very common use-case that I would have thought would be well supported.

If a command-line example is clearer to you look at:
http://www.mattb.net.nz/blog/dump/acl-inheritance-problems.txt

My current solution is to run a cronjob every X minutes to recursively ‘chmod -R g+w /dir’, however that’s far from optimal as it exposes all sorts of race conditions and just seems ugly!

Any suggestions or solutions will be gratefully received.

I’ve written a patch for the madwifi-ng driver to separate each associated client into a unique VLAN. The patch only makes sense for use when the driver is in master mode being controlled by hostapd. Using this patch with WPA2/RSN you can acheive complete layer 2 isolation between associated clients. The patch does not support placing multiple clients in the same VLAN.

Full layer 2 isolation requires that there is no broadcast or multicast traffic transmitted from the access point. To enforce this the patch mangles outgoing broadcast / multicast packets to be directed only to the node associated with the VLAN that the packet was received from. Clients can still send/recieve broadcast and multicast traffic without problems if you bridge them onto another layer 2 network. You must fully understand the consequences of this before using the patch.

In the worst case scenario if you bridged the VLANs for each client together onto a common L2 network you will cause every broadcast/multicast packet sent onto that L2 network to be transmitted by the access point as a unicast packet to each associated client. If you have a lot of broadcast/multicast packets this is going to significantly reduce the performance of your network. This is a somewhat contrived situation as there is no point creating the VLANs in the first place if you’re just planning to bridge them back together, but I use it to illustrate the risks this patch can introduce if you don’t understand it properly.

At this stage I’m not convinced that the patch is actually useful, and I’m not going to be proposing it for inclusion in the driver. You’re welcome to use it if you find it useful. Please let me know how you are using it and any problems that you run into. I don’t guarantee that I can provide support or assistance though

The Patch

• http://www.mattb.net.nz/patches/madwifi/per-node-vlan.patch

How the patch works
One of the primary constraints I had in writing this patch was that the clients using the access point are not required to do anything special. From their point of view they are simply associated to a standard AP running 802.1x with WPA2. There are no 802.1q packets “on the air”. All of the VLAN functionality is handled within the driver itself.

Inside the driver there is a node table listing every node that is associated. The patch adds an entry to each node record specifying a VLAN id for that client. By default this id is automatically assigned when a node associates, but it can be modified by wriiting to the /proc/net/madwifi/<iface>/sta_vlan file.

As packets are moved between the kernel and the actual physical card by the driver 802.1q tags are added and removed as appropriate to ensure that the kernel sees every node in it’s own VLAN.

The VLAN tagging code in the driver ignores EAPOL frames so that they are always sent to the base device where hostapd is listening.

Userspace Setup
By default per node VLANs are disabled and have to be explicitly enabled

echo 1 > /proc/sys/net/<iface>/per_node_vlan

And you almost certainly want to stop the driver from bridging packets between clients

iwpriv <iface> ap_bridge 0

Then it’s simply a matter of creating the appropriate VLANs on the base interface using the standard Linux VLAN tools, eg:

vconfig add <iface> 4


Final Comments
I’ve tested the code fairly extensive and it works fine for me. It’s not particularly clean and the mangling of broadcast/multicast packets is a messy hack. You can achieve a very similar situation using PPPoE from the client to the Access Point without having to patch the driver to support per node VLANs.

Yesterday’s patch for FreeRadius turns out to be superfluous, as the functionality is already present, its just undocumented!

I submitted the patch to the FreeRadius bug tracking system (#392) and got back a quick reply from Alan DeKok saying the following:

It isn’t well documented, but it’s already supported, via the
EAP-TLS-Require-Client-Cert attribute. This allows you to have
the cert requirement on a per-realm, or per-user basis.

Oh well, at least the patch didn’t take too long to write! I had seen the code that handles the EAP-TLS-Require-Client-Cert attribute, but I couldn’t find any references to it elsewhere in the daemon, so I assumed it was a fragment that was unused and ignored it.

Moral of the story: Assume less and spend more time understand the code you’re patching!

For the project that I’m dealing with at work I wanted to be able to authenticate devices in a two stage process. Stage 1 should authenticate the device to the network (via an x509 certificate) and then Stage 2 should authenticate the user who possesses the device with a username and password.

Unfortunately none of the methods shipped by default with FreeRadius will support this sort of configuration.

• EAP-TLS supports mutual certificate authentication between the server and the client but does not allow for a second stage to verify the username and password
• EAP-TTLS and EAP-PEAP both support mutual certificate authentication between the server and the client followed by a second stage password verification, however the current FreeRadius implementation doesn’t let you require a client certificate. If one is present it will use it, but it is just as happy to continue on without one, which is not ideal for my circumstances.
• The remaining EAP- methods don’t support certificates at all, so they’re not even an option.

A quick skim through the FreeRadius source code revealed that it wouldn’t be too hard to add support for requiring client certificates with EAP-TTLS and EAP-PEAP. The following patch adds a new configuration option to the tls section of eap.conf which if set to true will require the client to present a certificate before authentication will succeed.

• freeradius-require-tls-client-cert.diff

Example eap.conf

eap {
                default_eap_type = ttls
                timer_expire     = 60
                ignore_unknown_eap_types = no
                cisco_accounting_username_bug = no

                md5 {
                }
                tls {
                        private_key_file = ${raddbdir}/certs/radius.key
                        certificate_file = ${raddbdir}/certs/radius.pem
                        CA_file = ${raddbdir}/certs/cacert.pem
                        dh_file = ${raddbdir}/certs/dh
                        random_file = ${raddbdir}/certs/random

                        # This is the new option
                        # If set to no, or missing, client certificates are
                        # not required for EAP-TTLS or EAP-PEAP
                        require_client_cert = yes
                 }
                 ttls {
                        default_eap_type = md5
                }
        }

Back in April I mentioned the fun and games I had trying to get a nice dual-DVI setup working with my new HP dc7600. The other problem that I’ve been experiencing since then is a complete inability to play any audio.

The machine has an Intel ICH7 High Definition audio chipset onboard which is theoretically supported fine by the snd-hda-intel kernel module, and indeed everything loads fine and shows up in /proc correctly. However nothing ever comes out the speakers! lspci output below


0000:00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
Subsystem: Hewlett-Packard Company: Unknown device 3010
Flags: bus master, fast devsel, latency 0, IRQ 21
Memory at e0a00000 (64-bit, non-prefetchable) [size=16K]
Capabilities:


Today I sat down and tried to work out what was going on, it turns out the Realtek ALC260 chipset that is used on this motherboard supports quite a few different pinouts, so while snd-hda-intel knows how to drive it you don’t actually get any sound unless you have the correct mapping setup! The driver attempts to do this automatically for a number of different motherboards and there is a entry in the table for my particular motherboard (Subsystem 0×3010) mapping it to the ALC260_HP patching, but still nothing works!

Eventually I stumbled across ALSA Bug #2157 which fixes an identical problem for a different motherboard (Subsystem 0×3012) by using the ALC260_HP_3013 mapping in the driver.

So, taking a guess, I made the same change for the 0×3010 mapping, rebooted, and voila, I have sound. Patch below:


--- sound/pci/hda/patch_realtek.c.orig 2006-08-05 21:13:49.000000000 +1200
+++ sound/pci/hda/patch_realtek.c 2006-08-05 20:33:17.000000000 +1200
@@ -2951,7 +2951,7 @@
{ .pci_subvendor = 0x152d, .pci_subdevice = 0x0729,
.config = ALC260_BASIC }, /* CTL Travel Master U553W */
{ .modelname = "hp", .config = ALC260_HP },
- { .pci_subvendor = 0x103c, .pci_subdevice = 0x3010, .config = ALC260_HP },
+ { .pci_subvendor = 0x103c, .pci_subdevice = 0x3010, .config = ALC260_HP_3013 },
{ .pci_subvendor = 0x103c, .pci_subdevice = 0x3011, .config = ALC260_HP },
{ .pci_subvendor = 0x103c, .pci_subdevice = 0x3012, .config = ALC260_HP },
{ .pci_subvendor = 0x103c, .pci_subdevice = 0x3013, .config = ALC260_HP_3013 },


We use a lot of Soekris devices at work which often get deployed to remote locations where its not easy to access them if things go wrong. I’ve recently been writing some software to act as a watchdog on the machine. As a very last resort this software makes use of the watchdog chipset provided by the Soekris boards so that if userspace goes away the machine will get rebooted back into what is hopefully a sane state.

Unfortunately the in kernel sc520 watchdog device doesn’t actually reboot the Soekris when the heartbeat ping from userspace is lost. This makes it virtually useless. There has been a patch floating around since 2004 that fixes this problem, but it hasn’t made it in to the kernel for one reason or another. I think it’s Soekris specific…

I’ve updated the patch to apply cleanly against the sc520 driver found in 2.6.16 and you can find it below.

http://www.mattb.net.nz/patches/linux/soekris-sc520wd.patch

I signed up for a ZoomIn API Key (not that it seems to be needed atm…) the other week and finally got a chance to have a play this past weekend.

My test case was to build a map of all the CRCnet sites and the links between them to use as a plugin in the CRCnet Configuration System. Either as a dynamic status display (colouring links to show traffic loads and status etc) or as a network planning tool to get a feel for the relationship between existing sites and potential new locations. Obviously the lack of topographical information makes the second case far less useful than it could be, but I think even in 2D it would still be a useful tool.

Getting the points onto the map was relatively straightforward, but adding any sort of hover event to them was another matter. The GEvent class currently only supports the click event and markers are not added with any other identifying attributes (such as an ID or Name) which could be used to hook an event into them. After a quick squiz at the Terms and Conditions, I grabbed a copy of the API javascript and after unobfuscating it (basically just adding back in line breaks and running in through indent(1)) started to have a squiz at what was happening. The API code is very nice and clean and it wasn’t at all hard to work out what was going on. Mozilla’s Venkman javascript debugger absolutely rocks for this sort of work. It allows you to step through all the scripts on the page line by line and quickly get a feel for the flow of the code.

Adding support for the hover (onmouseover) event doesn’t look like it would be too hard, but the T&C didn’t explicitly mention whether I was allowed to actually modify the API code, so I choose to simply create a CRCnetMarker class (see below) that creates GMarker object and then pokes id attributes onto the internal objects of that class before returning it. Then once you’ve called addOverlay you can use the basic DOM functions to hook in an onmouseover event handler on the ID of the marker.

var CRCnetMarker = function (sitename, point, icon)
{
    var marker = new GMarker(point, icon);
    marker.icon.id = "crcnet_container_" + sitename;
    marker.icon.firstChild.id = "crcnet_icon_" + sitename;

    marker.addEventListener = function (eventname, handler) {
         b = document.getElementById(marker.icon.firstChild.id);
         b.addEventListener(eventname, handler, false);
    }
     return marker;
}
var marker = new CRCnetMarker(new GPoint(2704685.21,6367057.51), "mph");
map.addOverlay(marker);
marker.addEventListener('mouseover', hoverHandler);

That worked like a charm and I now have nice little info boxes popping up next to each node when you hover over them. I also discovered in the process of implementing this that Prototype and ZoomIn do not play nicely together. It appears to be Prototype’s fault as it messes with the Array type by adding new methods (like each for enumeration) which break the builtin for (i in array) syntax when the array contains non-numeric keys (like each). This has been reported in the prototype bug tracker as breaking Yahoo Maps but the comments don’t seem to offer much hope for Prototype’s behaviour changing anytime soon which is a pity.

The next roadblock was a lack of support for drawing lines! This put the kibosh on the whole animated network status idea. Trolling through the source again reveals a GPolyLine class that appears to be semi-implemented, so hopefully support for drawing lines is coming very soon.

The only other thing I found slightly annoying was having to supply all the co-ordinates in NZGD49 format. Most of our GPS information for CRCnet is stored in WGS84 format (as that’s what our older GPS unit puts out). NZGD49 has been deprecated in favour of NZGD2000 (which is near enough to identical to WGS84 for normal use) so I’m not really sure why ZoomIn is still using NZGD49. Maybe that’s all TerraLink can supply?

Some quick googling turned up the proj library (apt-get install proj in Debian) which provides the cs2cs utility which can convert from WGS84 (aka NZGD2000) to NZGD49 to feed to ZoomIn. The magic peice of information is the transformation parameters which LINZ helpfully provide. Punching those (I chose the 7 parameter version) into cs2cs via a command line like

echo "$lat $long" | /usr/bin/cs2cs +proj=latlong +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0 +nodefs +to +proj=nzmg +datum=nzgd49 +ellps=intl +towgs84=59.47,-5.04,187.44,-0.47,0.10,-1.024,-4.5993 | awk '{print $1" "$2}'

performs the magic conversion.

The conclusion?
Overall I think ZoomIn rocks and it’s really cool to see a small NZ company filling in where Google and friends have failed miserably.

The biggest weakness at the moment is definitely the API, which doesn’t really allow you to do much more than add points at this stage. Given that ZoomIn is still relatively young the leanness off the API is understandable. Given the API a few more months to mature and fill out and I think we’ll be able to create some really cool applications on top of the ZoomIn platform.

Screenshot: