Older blog entries for LaForge (starting at number 187)

FOSS.in is dead, PRODUCTISE.in lives

Team FOSS.in has announced lest year that the successful series of FOSS.in conferences has concluded. I'm still a bit sad that I was unable to make it to the grand finale.

But now, the very same team announces a new event called PRODUCTISE.in, with a different focus. It's not about Free and Open Source Software anymore, but about product developers - where the respective products of course could be FOSS based.

I remain curios to see what will happen to the event. Everyone who knows me knows that I'm probably a slightly pragmatic but otherwise orthodox Free Software fellow. As far as I can tell, the only proprietary software that I use (and license) in more than a decade is IDA Advanced.

But in any case, all the best to Team FOSS.in with their latest endeavour!

Syndicated 2011-10-15 02:00:00 from Harald Welte's blog

Ground-breaking research on APCO P25 security

While we at OsmocomTETRA have been looking only at implementing the TETRA protocols as they are (and doing a bit of sniffing on unencrypted networks), some researchers have recently published two ground-breaking papers on the (lack of) security in the APCO P25 radio system.

In case you haven't heard about APCO P25: It is a digital mobile radio system mainly used by Police in non-EU English speaking countries like the US, Australia and New Zealand.

You can find the respective papers here and here.

So apparently P25 uses either single-DES or a proprietary cipher with only 40 bit key-length. No, I'm not joking. Seems like it was developed by people who have not the slightest clue about communications security at all.

And guess what they used to receive and transmit P25 waveforms? Of course the USRP and gnuradio. This once again proves how invaluable those tools are, not just for the FOSS community, but also for the communications research community.

Syndicated 2011-09-18 02:00:00 from Harald Welte's blog

I'm still alive - short update...

In the last two months I barely found time to update this blog. I'm now back on track and will try to update the blog more frequently.

The CCC Camp 2011 has been great, and the OpenBSC based camp GSM network has been a success, despite some initial problems. Thanks again to everyone helping with the build-up and operation of it, and thanks for all our volunteer users/testers.

Most of the time since I've been buried alive in work, almost exclusively related to various sub-projects surrounding the Osmocom GSM protocol implementations. We're working on every level of the protocol stack at the same time, and on network elements from BTS, BSC up well into the core network, media gateways, etc.

Most recently I've been doing some work with

Syndicated 2011-09-18 02:00:00 from Harald Welte's blog

Ramblings on German battery law

Germany has laws for everything, including batteries (Batteriegesetz).

In order to be able to e.g. import products with batteries from outside the EU and sell them inside Germany (or the EU), you need to be registered as a battery manufacturer/importer. You also need to become member of one of the registered/accredited companies that take care of recycling the batteries (i.e. put small boxes in supermarkets where people can put their old batteries).

What's funny is that there is absolutely no lower boundary for that for small businesses. What that means for my company: I need to pay 1 Eurocent for each LiIon powered mobile phone to that recycling company.

I guess at current estimated volume, we will have to pay something like 1 to 2 EUR every year. The recycling company won't even send us an invoice if the amount is

So all this comes down is an exercise in buerocracy. We need to send a monthly report on the quantities every month, and there's a hard deadline that needs to be followed.

Furthermore, we need to put fancy stickers on each of the battery, covering at least 3% of the battery surface. That means opening every box, removing the battery from packaging, putting the sticker on it and re-packaging the box. Modern batteries normally have the symbol printed by the manufacturer, but we're talking about Motorola C1xx phones that have been produced from 2005 to 2008 here.

I certainly don't object to manufacturers or importers having to pay for the recycling. But if recycling is actually that cheap, and we're talking about single-digit EUR amounts per year, the administrative overhead (time needed for making the monthly reports, putting stickers on the batteries, etc) costs something like 100 times the actual recycling cost. Is that really worth it? Why not have a lower threshold for small businesses?

Syndicated 2011-09-06 02:00:00 from Harald Welte's blog

Major bugfix release of SIMtrace firmware

At the CCC Camp 2011, the Osmocom SIMtrace project was a major success. Not only were something like 60 units out of our initial batch of 100 units sold, but the SIMtrace workshop was so successful that it had to be held three times instead of once.

During the workshop we discovered a very annoying bug which I wasn't able to solve immediately. Depending on the combination of phone/simcard used, the SIMtrace would disconnect from USB and the phone would claim there is no SIM card inserted.

The debugging went like this:

  • SIMtrace was resetting very early in/after the ATR
  • the reset reason was diagnosed as being a watchdog reset
  • the watchdog was triggered by an IRQ storm from the USART
  • the IRQ storm was caused by the firmware not clearing some parity error / overrun related bits

However, at that point I couldn't further find the cause of the bug. I assumed it was related to the PPS/PTS, but couldn't really point my finger at it. If we sniff the PPS/PTS wrong, then of course our baud rate is different from the real baud rate, which in turn would cause perceived parity errors and the like.

I'm grateful that most people still didn't loose their interest in simtrace and happily bought the unit and/or attended the workshop.

After a bit more debugging after the camp, I have now solved the bug. I simply never realized that the TCK (ATR checksum byte) is only present in cards that support T=1 as well as T=0. However, some simpler SIM cards like the ones that we issued for our test GSM network on the camp only do T=0 and thus don't transmit TCK.

The old code thus considered the first PTS/PPS byte (0xff) as the TCK, and didn't recognize the PTS/PPS correctly.

Firmware version v0.2 fixes this problem. I've released the firmware update, now also available from the wiki

Syndicated 2011-08-16 02:00:00 from Harald Welte's blog

Update on the GSM network at the CCC Camp 2011

During the past weeks, I've been trying very hard to get to a technical solution for the setup regarding the private GSM network that we intend to operate at the CCC Camp 2011. Unfortunately, despite puting in way too much time that I don't have, no really good solution appeared. There were times when I was wondering if it would happen at all - mainly due to the lack of properly integrated / tested RF related issues like PA, LNA, duplexer, combiner, etc.

But it seems just in time Dieter came to the rescue. So now we have pretty much figured out the equipment and settled on a configuration. We'll have 2 Nokia Metrosite BTS with a total of 5 TRX, each running at 5W using borrowed equipment.

During the next 10 days, all the parts like antennas, cabling, plugs, adapters and the BTS units themselves should arrive at my place. Let's hope there are no serious fuck-ups that cause something to not arrive in time.

So all in all, there's a 99% chance we will have a functional GSM network. The Nokia A-bis support in OpenBSC will be brand new, so there might be some glitches here and there. But then, that's part of the fun. I'm already very curious to see what kind of coverage we get. I guess if we do things right, it should reach well into Finowfurt itself, and not just barely cover the camp grounds like we had at HAR 2009.

Syndicated 2011-07-22 02:00:00 from Harald Welte's blog

US government closing data centers and give up their independence

Sometimes I really think I must be dreaming. Who in their right mind would propose something like closing something like 800 government-owned data centers and outsourcing all the data to the cloud/>?

As a government, you

  • make yourself dependent from a private company to supply essential infrastructure
  • introduce single points of failure (technically, administratively)
    previously, you had 800 data centers, maybe each of them not as reliable as the advertisements of the cloud provider - but it is unlikely that all of them go down at the same time
  • give up control over who physically owns and has access to the data
    In fact, you will have a hard time even finding anyone at all who can tell you where your data is physically located. Maybe even out of the country?

Now you can argue that all those things can be put down in contracts as service level agreements (SLAs). That's true, but as we say around here: Paper is patient, meaning no paper is going to help you after data has been copied or was lost, and if you suddenly fail to provide basic services of the public administration.

The distributed nature of self-hosting your data and applications has key advantages in terms of security and reliability. Why would somebody give that up without a broad discussion? And we're not talking about some private company where nobody but their shareholders care if they loose data or go out of business. We're talking about the public administration here.

People seem to have lost perspective on the overall advantages of a heterogeneous, distributed setup.

Syndicated 2011-07-21 02:00:00 from Harald Welte's blog

On the recent THC release on the Vodafone femtocell

I am mainly posting this to prevent any more people mailing me about this release. There's nothing really spectacular here.

Starting from 2009 on, the usual suspects (aka OpenBSC developers) have been looking at various 3G femtocells, including the Vodafone one (I have 10 of them here). Aside from that Alcatel-Lucent design that Vodafone uses, we've also looked at the Cisco/AT+T/ip.access design, as well as the Ubiquisys/SFR one. With some effort you can root all of them, and you can then make sure they don't connect to the respective operator but to an IP address of your choosing.

The protocols are vendor-dependent. The Vodafone femtocell uses a version of RANAP (the protocol between RNC and MSC in UMTS) behind an 8 byte proprietary header. As RANAP is specified in the 3GPP, it was pretty easy to build a small piece of code that interacts with the unit.

Ubiquisys (used by SFR) uses the UMA protocols, and the Cisco/ip.access/AT+T design uses a proprietary ip.access protocol called URSL (sort-of a "progression" of the 2G RSL to UMTS).

Supporting them from OpenBSC is not easy. While the call control and SMS transfer protocols of 3G are identical to GSM, everything below doesn't really bear much resemblance. I would guess it would take at least a man-month to get basic signalling, call + SMS support working, if not more.

Given the fact that the femtocells all speak their vendor-proprietary dialects, and given that they often come with license terms that only permit the use of their firmware in combination with their gateway located at the operator network, we never thought it is a high priority item for us to work on.

What you also have to consider, is that their output power of 20dBm is even less than the 200mW of typical small-scale GSM BTS, and that they typically only support the operation of 4 concurrent phones. Nothing that you would be able to run e.g. a conference telephony network on.

Furthermore, due to the wide channels (5MHz), it is very likely that all available sprectrum has been auctioned off/licensed to commercial operators, so it's almost impossible to get something like a test license. In GSM with 200kHz channels, there's often still a guard band or some unallocated channel that can be used.

If you really want to have some free software + femtocell based 3G network, go ahead and do it. The option existed for years now, ever since femtocells started shipping to the market. All of them are some form of embedded Linux systems. Rooting them isn't really different from rooting a Linux based WiFi router / DSL modem. So what's that new about the THC release? That a vendor of Linux embedded devices chose a trivial password? If you're surprised by that, I guess you haven't taken apart many embedded devices then.

Syndicated 2011-07-14 02:00:00 from Harald Welte's blog

SIM-unlocking the Openmoko phones?

I think it's quite funny that SIM-unlicking vendors like RebelSIM actually advertise that their products are compatible with Openmoko, as you can see in this PDF file.

What's funny about this? Well, Openmoko phones have never been sold with any form of SIM or Operator locking. The entire idea was to have a phone that is under the control of the user, not the operator...

Syndicated 2011-07-06 02:00:00 from Harald Welte's blog

SIMtrace v1.0 prototypes are working out of the box

After the debacle with various wrong footprints in the v0.9, I'm very happy to announce that the SIMtrace v1.0 hardware is working fine. All footprints correct, schematics correct, layout/Gerber correct. All we had to do is solder the components, attach it to USB, flash the firmware and use it.

Here's a picture of the board (sorry, my soldering is not very clean):

Early next week we will be ordering a batch of 100 units from the SMT house we have chosen.

Syndicated 2011-07-02 02:00:00 from Harald Welte's blog

178 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!