Author Archives: Daniel Drake

Brontes are hiring a Gentoo expert

Here at Brontes Technologies we are looking to hire a Gentoo expert to join the systems group and help out with maintenance and development of our internal Gentoo systems and our Gentoo-based embedded medical product.

The company is based just outside Boston, MA and after being recently acquired we have an exciting ‘mature startup’ atmosphere but also the resources of a big huge company. The product is an extremely cool handheld 3D scanning device, due for launch later this year.

The company recognises the benefits of open-source and tries to work closely with development communities and contribute back where possible. We also make a large effort to utilise the standard open source support tools where appropriate — as an example, we use catalyst to build our product release media.

This is a full-time office position. If you are interested, see the full job description. To apply, email your resume to the address listed on that page, mentioning that you read about the position on my weblog.

Fingerprint export control news

I just noticed that the fingerprint group at NIST have dropped NFIS2 and created NBIS: NIST Biometric Image Software.

NBIS is split into 2 parts:

  • NBIS Non-Export Control: fingerprint quality analysis and feature detection tools. Source code available for download with no distribution restrictions.
  • NBIS Export Control: fingerprint comparison utilities. Not available for download, CDROM must be requested.

This is good news – it is now much clearer which parts of NIST’s software are subject to export control concerns, and additionally, NIST have clarified the reasoning:

It is our understanding that NFSEG and BOZORTH3 fall within ECCN 3D980, which covers software associated with the development, production or use of certain equipment controlled in accordance with U.S concerns about crime control practices in specific countries.

Unfortunately the freely downloadable part is not enough to finish dpfp or create a generic fingerprinting library, because the code required to actually compare fingerprints is only present in the export controlled part. However, I’m now in a position to continue researching the legal issues.

Pressing questions I’d have for any experts here:

  • What are the impliciations of ECCN 3D980 for an open source project?
  • Can I legally export the NBIS Export Control CDROM to the UK without having to fill out any associated paperwork?

Wireless Summit II

Earlier this month, I met with 25 other contributors at the 2nd Linux Wireless Summit. This was a followup from the 2006 summit.

The meeting happened in London and was scheduled to occur immediately after the IEEE 802.11 working group meeting. This enabled us to get some kind of vendor attendance.

While we had this opportunity, one of the biggest topics was discussion of why vendors still aren’t playing nice in releasing open source drivers (or providing the resources to let the community do so). The vendors in the room confirmed our suspicions – vendors are afraid of the FCC and other regulatory agencies who place restrictions on frequencies and power levels which these devices are legally allowed to transmit as.

Matt Norwood from the Software Freedom Law Center was in attendance and had studied the FCC regulations in some detail. The conclusion is that the FCC rules are vague and while they don’t explicitly say that open source drivers are not allowed, vendors are not prepared to risk falling out of compliance and are playing it safe (or not playing at all). Unfortunately there is no short term solution to this: it would take years for the FCC to clarify the regulations. Short term workarounds such as finding ways to encourage vendors to produce open drivers with only the regulatory part closed (such as Intel’s ipw3945 offering) are under investigation.

The other large topic was the merge of the new wireless stack (d80211) which was donated to the community by Devicescape. The stack has many more features than the current in-kernel ieee80211/softmac stack, and improves consistency between drivers. We are now much closer to getting d80211 merged into mainline Linux, but there are still some significant technical issues to be resolved.

Before the conference, several people asked me if I could raise issues with the suckiness of Intel’s ipw3945 driver offering in that it relies on this awkward closed-source userspace daemon. Fortunately Intel have found a way to rewrite their firmware so that the regulatory domain control is no longer at the driver level, therefore a fully open-source driver with no binary userspace part has been developed (iwlwifi). Although Intel have not yet announced it, the source code has been released here. This rewritten driver uses the d80211 stack mentioned above, so it’s not possible just to compile it against mainline Linux at the moment. The iwlwifi website includes instructions for how to check out the wireless-dev tree where d80211 is being held.

All slides and notes from the conference can be found here. Stephen Hemminger wrote a more detailed summary. Also, one other significant product of the summit was a central information source aimed at Linux wireless users – we have now launched linuxwireless.org.

Misc updates

  • I hope to continue my investigation into the fingerprinting legal issues within the next few days. This is currently on hold while I’m waiting for information from a few people.
  • With help from Matthieu Castet and Johannes Berg, I’ve been reverse engineering the firmware for the ZD1211 wireless devices. We understand approximately 85% of the instruction set. Assuming we can figure out the remaining details, we’ll be able to write an open source firmware at some point in the near future. My assembler, disassembler and notes can be found in a git tree (gitweb, clone URL).
  • I’ve moved touchcal to sourceforge and taken over maintenance. I fixed it up to work better with EloGraphics screens, but do not have any immediate plans to develop it further. Contributors/contributions are welcome.
  • Anyone affected by the recent VIA IRQ quirk problems in recent Linux kernels should try Alan Cox’s fix against 2.6.19-rc. If you have no idea what I’m talking about, then ignore this.
  • USA is great, thanks for asking! I’m especially looking forward to my first ever thanksgiving :)
  • Last week I saw the Boston Bruins battle it out with the Buffalo Sabres. Thanks to a company sponsor we had seats in a members-only premium suite. The atmosphere was great, Boston were 4-1 up but unfortunately the Sabres came back late in the game and won 5-4 in the shootout.

ZD1211 driver news

Despite not mentioning it here for a while, Ulrich Kunitz and myself have been driving forward with our ZD1211 USB-WLAN driver rewrite.

For a start, the driver is included in the recently released Linux 2.6.18 kernel, which has resulted in a drastic increase in the number of users. If you’re looking for a handy way to add wireless connectivity to a computer now and then, these devices are ideal: cheap, small, reliable, in-kernel driver, redistributable firmware.

A more functional driver can be found in the 2.6.19-rc development tree. New features include:

  • LED support – the light goes blinky blink during network usage.
  • Support for devices based on the AL7230B RF (i.e. ZD1211-based devices which support 802.11a). We don’t support 802.11a connectivity just yet, but you can now use these devices to connect to b/g networks.
  • Out-of-the-box support for driverless devices (not even the vendor driver supports this!).
  • More accurate signal strength/quality statistics.
  • Many more device ID’s added thanks to people testing the driver with their hardware.

Coming for 2.6.20: ERP handling (to play nicer when 802.11b clients are in sight), hardware decryption, and more! Many thanks to ZyDAtheros for their continued support.

Post-it notes and adhesive tape

Monday was a very eventful day at work. I started my co-op placement at a small-but-mature startup company less than 2 months ago, and yesterday morning we are herded into a meeting where it is announced that we have been acquired by 3M. The buyout is especially interesting given that Brontes is still a pre-sales company.

3M is an amazing organisation, notably in terms of their scope. You name it, they make it. Post-it notes, dental products, pharmaceuticals, scotch tape, chemicals, health care products,skincare product like under eye masks, etc. It’s really exciting as we’ll now have a huge amount of global resources to tap into. I’m really happy that I get to experience this while on my placement year.

More details here.

More export control material

Donnie Berkholz pointed out that the Xorg project previously had to overcome some issues with export control vs cryptographic code. I haven’t had a chance to chew on it yet, but there seems to be some good info here:

I’m at the GNOME Summit this weekend, and today I met Jim in person. We talked briefly on the topic which was useful. After going through the above info I’m going to contact the Software Freedom Law Center based on his advice.

Fingerprinting legal issues update

Thanks for the responses to my plea for help up to this point. I’ve also contacted a few people who I’m waiting for responses from.

I’ve been told that most of NFIS2 will become a downloadable open source project soon, which is encouraging. However, this project will NOT include the fingerprint matching algorithm, instead it will only include the analysis tools. This implies that scope of the export control issues is limited only to the actual matching and identification part, and leaves me with exactly the same problem.

I’ve also been informed that NFIS2 distribution is subject to ECCN 3D980. Basically, if your export can be classified under the ECCN, you need a license before you can export it (at least this my is interpretation, which may be wrong). Such licenses aren’t exactly open-source compatible.

Previously I was only looking under category 4 (Computers) but apparently they also put software under category 3 (Electronics). Here’s the text of 3D980:

“Software” specially designed for the “development”, “production”, or “use” of items controlled by 3A980 and 3A981.

3A980 is unrelated, but 3A981 says:

Polygraphs (except biomedical recorders designed for use in medical facilities for monitoring biological and neurophysical responses); fingerprint analyzers, cameras and equipment, n.e.s.; automated fingerprint and identification retrieval systems, n.e.s.; psychological stress analysis equipment; electronic monitoring restraint devices; and specially designed parts and accessories, n.e.s.

Opinions or thoughts on the interpretation of this new info are much appreciated.

NFIS2 works!

Despite the earlier legal concerns about libdpfp (which still stand), I went ahead and requested a NFIS2 CD and integrated it into libdpfp locally.

The good news: it works brilliantly. Minutiae detection and comparison completes instantaneously and the results appear to be accurate and reliable. In other words, if I scan my finger twice it says its the same finger, and if I scan two different fingers it says they are different. I’m now in a position to follow up my larger plans of producing a generic fingerprinting library for a range of hardware, except…

The bad news: I’m not going to distribute any more work on libdpfp until I have found legal advice which tells me it’s OK to do so. I’m now at the position where I have a load of code I can throw at lawyers and say “this is exactly what I want to distribute”, so this is where the hunt begins.

If anyone has suggestions for people I might contact (even non-legal types who might be able to pass me on to someone), or has experience seeking advice in this kind of area, please contact me. I’m aware that such advice will probably cost money, although I don’t have any idea how much. Raising funds to cover costs might be a possibility.

In summary I’m looking for someone who understands (or can figure out how to interpret) US export control laws. I guess I also require a tech type who understands the concepts of software distribution to some degree. Any guidance appreciated!

In-kernel ALSA support in Gentoo

I think some people might have misunderstood Diego’s post about ALSA support in Gentoo.

To clarify, we (as in Gentoo kernel maintainers) do support in-kernel ALSA drivers, but Diego (who maintains the out-of-kernel alsa-driver package) does not. I recommend using the in-kernel drivers, Diego recommends using the out-of-kernel drivers.

If you do have problems with the in-kernel version, please do file bugs, but make sure they get assigned to kernel@gentoo.org rather than Diego.