Matt's Musings

September 22, 2006

Requiring client certificates for EAP-TTLS with FreeRadius

Filed under: Linux — matt @ 3:07 pm NZST

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.

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
                }
        }

August 5, 2006

Working sound on an HP dc7600

Filed under: Linux — matt @ 9:12 pm NZST

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 },

July 17, 2006

Patching the sc520 watchdog to reboot Soekris devices

Filed under: Linux — matt @ 12:06 pm NZST

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

May 18, 2006

Playing With ZoomIn

Filed under: Linux,WLUG / LinuxNZ — matt @ 12:04 am NZST

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:

April 18, 2006

Desktop with Dual-DVI

Filed under: Linux — matt @ 7:37 pm NZST

I recently aquired a new desktop for work which came with a 17″ Philips LCD screen. Given that I work from home and I already owned a 17″ LCD the scene was set for a nice dual-head setup, or so I thought. Having two LCD monitors side by side, I wanted them both to be running on DVI. This was not to prove an easy task.

The first hurdle was finding a video card with Dual-DVI output for a reasonable price. This was made even harder by the fact that I was originally looking for a AGP card to avoid having to upgrade the entire motherboard. Eventually we gave up on this option and I ended up getting an HP dc7600 mini tower with a PCI-e slot to use for my desktop. We also ordered a Power Color card based on the Radeon X1300 chipset to satisfy the Dual-DVI requirement.

Unfortunately when the machine arrived (around the end of March) I discovered that the X1300 was not yet supported by the open source X.org drivers and, even worse, there was no support for it in the latest fglrx release from ATI either! This was sloppy checking on my part really. I’ve become so used to hardware “just working” thanks to Ubuntu that I didn’t even consider that the card might not be supported. I filed a support request with ATI asking when support for the X1300 was expected and received the standard “Linux isn’t supported, not aware of any upcoming revisions, we’ll support it when we get around to it” style response. Eventually we found an Radeon X850 based Dual-DVI PCI-e card for around twice the price of the X1300 and ordered that. I limped along with a single screen using the VESA driver until the card arrived.

Initial impressions with the X850 card were not promising. Although it is supported by the radeon driver in X.org 7.0 there seems to be a bug that prevents it from working correctly in Dual-head mode. There are numerous tickets in the X.org bugzilla and the problem appears to be solved if you use DVI+VGA, but its still broken for DVI+DVI unfortunately. Next step was to try the fglrx drivers to see if I could get Dual-head working with them. More problems! fglrx doesn’t play nicely with Xen (I run my desktop in a Xen dom0 with other testing domains (for sid, etc) in domU’s). After reverting back to the standard Ubuntu kernel (eg. no Xen) I’ve managed to get a nice Dual-DVI Dual-Head setup working with the X850.

However, in the process of installing the fglrx drivers I discovered that there had been a new release made on the 12th of April that among other changes added support for the X1300 chipset!!! Needless to say I’m not particularly impressed with the response from ATI’s helpdesk, given that only one week prior, they had disclaimed any knowledge of when support for the X1300 chipset would be available. As it turns out, its a bit of a non-issue anyway as I couldn’t make the X1300 work properly in a Dual-DVI setup. The secondary screen suffered all sorts of corruption and ghosting that I couldn’t work out how to remove. Running the second screen in VGA mode (via a DVI-VGA adaptor) was fine, but with a drop in quality due to the VGA connection.

So after several months of waiting, almost a day of configuration twiddling and the loss of Xen. I finally have a Dual-head, DVI based desktop setup. Its very nice, but the cost is certainly high. I can’t believe that Dual-DVI doesn’t seem to be widely used, am I really that fussy about my monitors?

Now that I’ve had to give up Xen, I’m trying to get VMware setup to do the job, but I’m already running in to problems there. VMware refuses to use LVM devices for raw disk access and the LD_PRELOAD solution provided by vmware-bdwrapper is not playing nicely with dapper’s multiarch setup at the moment. Hopefully with another days worth of twiddling I can get it working!

April 8, 2006

Porting code to Windows

Filed under: Linux — matt @ 12:30 am NZST

I’ve set myself the task of porting libtrace to Windows, so that Perry and I can use it in an upcoming project that we’ve been scheming for a long time. It’s going to be a reasonably large job I think!

For a start its going to involve relearning all the MSVC oddities that I knew back when I last wrote code for Windows (over 4 years ago) and then there is all the stupid compatibility issues between various header files and type definitions to work out.

I haven’t been able to find a good document that lists all the common problems that you run into porting a GNU library to Windows which surprised me somewhat. There are plenty of documents about how to port code from Windows to Linux however. If anyone knows of some handy resources I would love to hear about them.

Cygwin/Mingw32 etc are not suitable for this project.

March 14, 2006

Response to the SSC Legal Guide on OSS

Filed under: Linux — matt @ 10:53 pm NZST

I promised that I would post again stating how I thought NZOSS should respond to the SSC legal guide. Instead I got caught up helping Peter actually draft the response.

I was only involved in the first few drafts before I had to turn back to real work, however Peter and many of the other NZOSS participants finished off the document. I think the final product is slightly more verbose and touches on more points that I would have raised personally, but I do think it sets the right tone overall and certainly won’t do us any harm.

This seems to have been justified by the news today the the SSC has offered to fly two representatives of the NZOSS down to Wellington on Friday to meet and discuss the document. I would have liked to have gone, but given that I’m going to be attending NZNOG for most of next week I don’t think I can really justify the time off work.

It would be good to link to the actual response itself about here, but as far as I’m aware its not up on the NZOSS website yet. There is an earlier draft at http://www.devcentre.org/ssc-response-legal-guide-oss-2006-03-08.pdf which is very close to the final in content. I think only grammar and minor formatting was changed after this point.

Now we sit back and wait to see what the SSC will do after the discussion on Friday. All in all I think this whole episode has underscored how healthy the level of open source support within the NZ government is.

February 17, 2006

2.6 Suckiness

Filed under: Linux — matt @ 11:46 pm NZST

Has anyone else noticed a sharp decline in the quality and stability of the 2.6 kernels recently? I know that they’ve supposedly done away with “stable” releases and changes are being merged from the development trees straight into the 2.6 mainline, but surely we can still expect some level of stability. I’ve run into some fairly major problems lately.

In early December I tried to upgrade our Biscuit PC distributions kernel package from 2.6.13.1 to 2.6.14 but was stymied by the fact that 2.6.14 seems to have completely removed support for building out of kernel modules against the kernel headers only, the full kernel source is now required to be present. This does not play nicely with Debian kernel packages. I haven’t had time to try 2.6.15 yet to see if this change has been reverted, but its a fairly major thing to drop support for and completely removes the ability for me to build packages for external drivers like madwifi.

Today I was upgrading a machine with software raid from Woody -> Sarge and proceeded to upgrade the kernel too. I pulled down a copy of 2.6.15.4, ran make oldconfig and then verified that all the crucial options were still selected (raid, promise controller, e100, etc). make-kpkg, dpkg -i, reboot. BANG.

VFS: Cannot open root device "md0" or unknown-block(9,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0)

A quick investigation revealed the promise controller as the source of the problem

PDC20267: IDE controller at PCI slot 0000:02:0e.0
PDC20267: chipset revision 2
PDC20267: ROM enabled at 0xf4640000
PDC20267: 100% native mode on irq 22
PDC20267: neither IDE port enabled (BIOS)

Now, the Promise controllor is certainly not disabled in BIOS, and 2.4.21 manages to boot off it just fine so what is wrong with 2.6.15!? Google suggested that I needed to enable the PDC202xx_FORCE option, (which was enabled in 2.4.21 but in 2.6.15 is only available if you happen to select the completely unrelated driver for the next model up promise card to what I have – a bug that has apparently been acknowledged since 2.6.9 but still not fixed!!), however that made no difference whatsoever.

After a couple of hours of fiddling around with various kernel settings and boot options (did I mention this machine is 200km away from me…) I gave up and started trying early kernel versions starting with the existing 2.6.13 kernel I was using for the Biscuit PC distribution, which worked first time. So far I’ve not been able to find any other reports of problems with 2.6.15 and the Promise drivers, but from what I saw today they are completely non functional.

The common argument I seem to hear when I usually mention this subject (2.6 suckiness) is “but you should just use your distributions kernel”, to which my reply is “but I do…”, for my desktop. The standard Ubuntu kernels work great and I have had no reason to meddle with them.

However my desktop needs are a far cry from what I need to be able to do for the servers I maintain at work, or the kernel packages that I need to build for our BiscuitPC distribution. I’m certainly not one of those gentoo type people that need the latest and greatest the instant that it comes out, and I don’t try and run the latest kernel just for the sake of it. But the fact is, new kernels bring new features (not to mention bugfixes and security patches) that are frequently needed, especially in the networking and wireless areas. When I have to spend several days debugging and testing every time we need a new kernel only to find some critical flaw that prevents us from using it I have to stop and wonder whether the current kernel development process is working.

Have others had similar experiences with 2.6 kernels recently, is the fact that the latest kernel-image I can find in sid is 2.6.8 confirmation that it’s not just me, or am I really just overly angry due to the hours I’ve spent battling 2.6 lately?

Update: Several people have pointed out that I failed to look for linux-image instead of kernel-image and that 2.6.15 is already in sid. My mistake. And yes, I do plan to file bugs, not just rant, but sometimes you need to vent first :)

January 25, 2006

LCA’06 Update

Filed under: Linux — matt @ 2:08 pm NZST

Finally on the third day of the LCA (or the first day of the conference proper) depending on how you look at it, I’ve had a chance to sit down and catch up on a few things .

I managed to take on the task of running the network for the conference, and as we all know, the geeks need their network access. We’ve had some issues getting the network up and running which has been interesting. Most of the problems were caused by issues with incorrectly configured rate shaping on our upstream link which was limiting our outgoing capacity to about half of what it should have been. Once that got sorted out we discovered that the fibre tranceiver was not playing nicely with the NIC in the linux router we had been lent use of for the conference. This led to 20% of packets being dropped, and severely hampered usage of the network! When we swapped the dodgy NIC out for a new Soekris box it was immediately obvious that the connection “felt” better and the usage immediately spiked up over 3Mbps.

By far the most prominent form of access at the conference is via wireless, we have 25 APs around the conference, built using Soekris net4526 biscuit computers and Atheros 802.11a/b/g wireless cards. We’re managed the network using the CRCnet Configuration System, which I also plan to introduce to the world during my talk tommorrow.

We were a bit worried that we had overprovisioned the wireless, however the usage stats that we’re seeing seem to suggest that it’s about right. Earlier this morning we peaked with just over 210 concurrent clients on the APs and almost 5Mbps (our limit) of traffic coming in / out of the network.

We’ve implemented some interesting protection strategies on the APs to try and prevent ARP spoofing attacks, although writing software like this in the week right before the conference and then trying to debug it as you build the network turns out to be not such a great idea!

Currently sitting in listening to a talk by Brendan O’Dea about the high volume l2tpns software that they’re written at Optus. Very interesting.

January 22, 2006

At LCA06 – Busy Busy Busy

Filed under: Linux — matt @ 11:30 pm NZST

Haven’t posted for a while. At LCA06 in Dunedin since Thursday, network is finally up and running. Still lots to do!

« Previous PageNext Page »

Powered by WordPress