Older blog entries for LaForge (starting at number 223)

29C3. The end of an era?

When I first heard that the annual CCC congress was moved to Hamburg, my immediate reaction was: Fine, but I wouldn't want to be involved in it. For the last 15 years I've been attending the CCC congress every year, in most years as a speaker, and in many years in some (small) contributing role, first in the team doing the video recordings, and in the last couple of years setting up a GSM network. Contributing to an event is easy if your home/lab is within 20minutes, so if you need another strange cable/adapter/tool/whatever, you can just go and grab it. Doing that at an event that's multiple hours of driving away, in a new/unknown venue is an entirely different story. I have more than enough stress already with (paid) work and the various FOSS projects that I'm leading or involved in.

I have no interest in "just" attending the event. That never was a primary reason for me. In all those years, I've probably attended an average of one talk each year. The event for me was about being able to contribute something actively.

Now, months after those thoughts and my decision not to attend, there is a schedule for the 29C3 available. And to say the least, I am shocked. The entire event seems to have turned into a SIGINT, rather than an xxC3. Lots of talks on politics and society, and lots of German talks.

The debate on implications of technology on society, culture, politics, etc. is an important debate, there is no doubt. And so far I always had the feeling that the xxC3 had a pretty good balance between hard-core technical talks and those non-technical talks. But if I look at the schedule this year, it really looks like an incarnation of the SIGINT conference. With too many German talks you are scaring off the international community. And with focussing on non technical topics, you scare away the die-hard technical hackers. So why move to a larger venue, if you at the same time seem to limit the scope of the event?

Meanwhile I have heard of a number of friends and colleagues who seem to share this view. A number of people who have attended in previous years are not interested in attending this year due to the issues mentioned above.

It's sad to see, but I somehow have the feeling that 29C3 might be the end of an era. The end of a highly successful series of events with exceptionally strong technical talks. To me, xxC3 has always been unique and special. No other event would ever compare to it. Who will fill the gap for the die-hard technical topics? I am feeling quite sad, up to the point that I want to start mourning about "the good old times".

I'm not writing this to put blame on anyone. It just reflects my personal and highly subjective view. Let's see what people will say after 29C3 has actually happened. Let's see how successful it is in terms of number of attendees, and in terms of feedback from participants.

Syndicated 2012-12-18 01:00:00 from Harald Welte's blog

Inside a cavity duplexer

In many cellular systems (GSM or otherwise) there is a frequency duplex between the uplink and downlink frequency band. If you use a single antenna to serve a BTS, then somehow you need to split the frequency band between the Rx and Tx side by means of a Duplexer.

The most common technology for this is the so-called Cavity Duplexer. I've used those devices (and seen them in use) for a long time, but never really opened one so far. The problem is that they are finely tuned, and each mechanical change can severely impact performance. As I had to repair a broken SMA socket on one of them recently, I took the chance to take a picture

In the first picture you can see the bottom side. This consists of a milled aluminum block, with a series of circular cavities. The Tx output of the BTS is connected to the SMA socket on the bottom right, the antenna to the SMA socket on the top side, and the Rx port to the SMA socket on the bottom left of the picture:

The small cylindrical objects in the center of the cavities are not milled from the same part, but they are separate pieces mounted by screws from the bottom of the unit.

The second picture shows the top section of the duplexer:

You can see a ~ 4mm aluminum plate with lots of (now empty) holes which are for the ~ 117 screws with which the top plate is screwed against the bottom part shown in the first picture.

The important part, however, are the screws that you can see sticking out of the top part. Those are used for tuning and present "obstacles" in the path of the waves as they pass through the cavities.

The big miracle for me is not that there are some resonances which build up a filter, but that you can actually transfer as much as 100W of RF power from the Tx input through to the antenna output.

Syndicated 2012-11-22 01:00:00 from Harald Welte's blog

Short report on the first Osmocom User Group meeting in Bavaria

It's already one week in the past, but I'm only now finding some time to report on the first Osmocom User Group meeting in Bavaria.

All-in-all, there were 6 people attending, some people already known in the community, but also two completely new faces, which is great.

Dieter gave us a tour of his large BTS equipment, including a Nokia Ultrasite and an Ericsson RBS 2206. We had an introduction round where the participants could get to know each other a bit. Finally, we spoke about a variety of topics, from OsmocomBB to SIMtrace, SIM/SAT/STK security, the CC32RS512 and of course OpenBSC and the sysmoBTS.

On the day after the meeting I also had the pleasure of attempting to get the RBS2206 working with OpenBSC. Unfortunately there was no success, but still a number of bugs in the OM2000 / RBS2000 code in OpenBSC that had been found and fixed.

I'd like to thank Dieter Spaar for organizing and hosting the event, taking care of the Bavarian sausage + cheese platter for lunch.

Syndicated 2012-09-08 02:00:00 from Harald Welte's blog

I did not create rtl-sdr / librtlsdr

In recent weeks, the number of private e-mails I receive about rtl-sdr has increased significantly. This is odd for at least two reasons:

First, I didn't create rtl-sdr and was not involved in its creation with the tiny exception of writing an e4k tuner driver for osmo-sdr, which was then used in a variety of rtl-sdr software.

Second, you should never contact the (presumed) software author in a private e-mail, but use the respective project mailing list. There is a community of developers, contributors and users out there, and it is a waste of everyone's time if you communicate by 1:1 private e-mail rather than enlightening the mailing list.

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

We're now working on a UMA/GAN controller

We've pondered it a couple of times in the past whether we should implement an UMA/GAN controller (UNC/GANC). GAN (formerly called UMA) is a method by which you can tunnel GSM/3GPP Layer3 signalling (Mobility Management, SMS, Call Control) over an IP based bearer such as 802.11 (WiFi).

The idea was that mobile phones that support both a GSM/3G radio as well as WiFi could then simply use WiFi to connect to their mobile operator. This has been deployed around 2007/2008 by some operators such as T-Mobile USA as well as Orange UK. Today it seems that not many operators have caught up and UMA/GAN is mostly a legacy technology, last but not least due to very few phones actually implementing it.

Nonetheless, there are some markets and applications where UMA/GAN is useful. We (Dieter and I) now have managed to secure a contract for an Osmocom implementation based on OpenBSC (and libosmogsm, libosmo-sccp, ...). The beauty is that from L3 up, it is just regular GSM, no change needed at all. Only the transport layer is different: IPsec with TCP + GAN is the bearer, instead of LAPDm/RSL in classic GSM networks.

Another good part unrelated to UMA/GAN is: This will finally force us to clean up the separation between the MSC and BSC part in OsmoNITB (in order to replace the BSC part with the GANC).

Progress has been good so far, the SEGW (IPsec with EAP-SIM) has been configured, and a simplistic start of a GAN protocol implementation gets us through DISCOVERY, REGISTRATION and up to the point where the MS is sending the LOCATION UPDATE message. If you are curious how the protocol actually looks like, I've attached a sample pcap file to the WRTU54G-TM page in the OpenBSC wiki. The source code can be found in the laforge/ganc branch of openbsc.git.

Syndicated 2012-06-24 02:00:00 from Harald Welte's blog

First month of running the openmoko.org USB Product ID registry

One month ago, I had announced the availability of USB Product IDs under the Openmoko USB Vendor ID. By now, there have been 37 registrations, and the List of assigned USB Product IDs in the openmoko.org wiki is turning into something like a directory of really cool projects with Open Hardware or at least Free Software device firmware.

So actually, I enjoy a lot seeing so much activity in this field, and being able to contribute a tiny bit by enabling people to get a unique USB Product ID that they can use.

Syndicated 2012-06-21 02:00:00 from Harald Welte's blog

Back from a 3-day motorbike ride to the central Taiwan mountains

I've wanted to do this for many years, but somehow never managed to do this even back while I was spending a lot of time in Taiwan: A motorbike ride crossing the mountainous center of the island using the Central Cross-Island Highway. This highway is probably not what most people imagine a highway would be like: A narrow road consisting almost entirely only of serpentines with a speed limit of typically 40 km/h. In other words, a motorbiking paradise.

You can enter that highway from the east by starting from Taroko Gorge. In order to get there by motorbike, you take the famous Provincial Highway No. 9 from XinDian via Pinglin to Yilan, which is frequented a lot by Taipei motorbike riders on weekends. The No. 9 further leads along the cliffs of the coast to Xincheng, from where No. 8 starts.

The trip from Taipei to Xincheng is only about 200km, but still you need at least something like 5.30 hours if you want to ride safely. This is once again due to the mountain roads. You can barely see 100m at any given time to the next turn in the road all the way between XinDian and Yilan.

So I stayed one night at the entrance of Taroko Gorge.

Upon arrival I was greeted by the hotel owner with the news that No. 8 had been closed temporarily due to rock fall at km 150.9. That was pretty devastating to my plan, as this road is the only connection in the northern two thirds of the entire island. There is no alternative, except for No. 20, which would have been probably three times the amount of distance (and thus time). However, as it later turned out, the road would be opened for 30 minutes between 6am and 6.30am. So I had to leave at 5.00am in order to safely ride the first 30 km up to the road block. This turned out to be the best thing that could have happened:

• There was absolutely zero traffic in either direction (the first 25km to Tienshang that are normally full of tourist busses).
• I was able to witness the sunrise at about 5.40am in the mountains
• very clear sight, which at other times is not clear at all

So I reached the road block even ahead of schedule and was able to pass as intended.

I continued along the road, and due to the fact that the road was closed again after 30mins, there was close to zero traffic all day on the entire road. /p>

At Dayuling, you can either continue the 8 towards Lishan (but not much further due to repeated subsequent earthquake and typhoon damage), or you an continue along No. 14 A towards Hehuanshan (Mt. Hehuan). I first went to Lishan (a major tea planting region) and back, as due to my early morning start I had lots of time left for detours, to continue towards Mount Hehuan , where the road reaches an altitude of more than 3100m.

I spent the second night in Renai, where I arrived just in time: The first rain drops of a heavy afternoon thunderstorm were falling. In the morning, I was greeted by the following view from my hotel room:

I left again in the early morning, drove through Puli and headed for the Sun Moon Lake. It really is beautiful, as you can see in the following picture. However, it is also over-developed to care for tourists of all sorts, including lots of concrete directly at the lake, and bus-loads full of tourists, Starbucks coffee shops and everything that comes with it. After two days in remote mountains with little buildings and almost no people, the experience was so shocking that I decided not to circle the whole lake but instead continue down south along No. 16 until it meets No. 3, which I then drove more or less all the way back to Taipei.

The first sixty-or-so kilometers are painful, as they lead through heavily populated areas around Nantou and Taichung. This means that there's lots of traffic, and very frequent traffic lights that make you stop. Later on, the road leads through less populated mountainous regions, and driving is more relaxed again.

Having managed this trip without any problems (nor getting lost even once), I'm hoping to find some time in the future to ride No. 7 from Yilan to Lishan, and particularly Provincial Highway No. 20, crossing the mountains much more south.

And if there's one part for me to remember: Always avoid the densely populated regions in the west of the island. If I wanted to ride stop-and-go all day long, I don't have to leave Taipei or New Taipei City in the first place ;)

Syndicated 2012-06-10 02:00:00 from Harald Welte's blog

Kevin Redon starts collaborative Osmocom project to collect terminal profile

As Kevin Redon writes in his blog, he has created some tools and a project for collaboratively gathering a database on the TERMINAL PROFILE capabilities of mobile phones.

The terminal profile describes which particular features regarding proactive sim or sim application toolkit a given phone supports.

This is not only important for SIM application / SIM toolkit developers, but it is also an important factor when trying to analyze the potential threat that can originate from a malicious SIM card attack.

I personally see no reason why my phone should ever report its GPS position to the SIM card, or why the SIM card should be able to re-write the nubers I'm dialling. Yes, there are cases where such features are useful, but then they should be explicitly enabled by the user, and the default should be that they are all switched off.

Who knows, after all, with some attention to this problem we might still see a SIM firewall / proxy, that you can put between the SIM and the phone to prevent any of those features from being (mis)used.

So all you need to do to contribute to the database is some way how you can read out the terminal profile from your mobile phone(s), and use Kevin's tool to upload it to the public website. And hwo do you read out the terminal profile? For example by using Osmocom SIMtrace to sniff the communication between SIM card and phone.

Syndicated 2012-05-21 02:00:00 from Harald Welte's blog

osmo-lea6t-gps timing module DIY kits available

Due to lots of other work, it took quite some time between my initial blog post about the omso-lea6t-gps board and the point where we are able to offically sell kits in the sysmocom webshop. The primary reason is: The people for whom we primarily built the board (i.e. the Osmocom developers) all have one and are happy with it ;)

But repeated inquiries by e-mail and otherwise have shown there is more interest. However, for a hand ful of boards we cannot make an automated production run in a SMT assembly line. So for the time being, we are only selling DYI kits, consisting of a digikey-packaged component kit including all components, plus the PCB, as well as the LEA-6T module.

Anyone who is interested in such a timing module DIY kit can now order from the sysmocom webshop.

More information on the project, including design materials like schematics can be found at the Osmocom wiki.

Syndicated 2012-05-20 02:00:00 from Harald Welte's blog

Announcing the low-power, light-weight sysmoBTS

It hasn't been a secret that when I co-started a company called sysmocom more than a year ago, it was not about opening a webshop that sells cheap phones and DYI electronics kits to the larger community. Rather, it was to develop and sell exciting products surrounding Free Software and mobile communications.

There are of course the more or less obvious things to do, like system integration of OpenBSC and the related software on embedded systems, selling them as appliances including training, support and maintenance service.

However, we of course also want to more than that. Today it is my pleasure to say that the availability of our first BTS product called sysmoBTS has been officially announced.

See the news item, the product page and the data sheet for more information.

To make it very clear in the beginning: sysmoBTS is not an open hardware project. The schematics and layout files are proprietary and not disclosed publicly. Such is the FPGA bitstream and the layer1 inside the DSP.

However, any code running on the integrated ARM processor is available as free software. This includes a yocto/poky-built Embedded Linux distribution featuring u-boot, the Linux kernel (including all kernel modules!), the osmo-bts and OpenBSC software as well as many other Free Software packages.

We think this is a reasonable compromise between espanding a bit from our previous "BSC and above in Free Software" down to a "BTS Layer2 and above" divide. After all, if you use OpenBSC with a BTS from Siemens, Ericsson, Nokia or ip.access, you don't have access to the source code of anything running inside the BTS at all.

sysmoBTS offers some great new capabilities, such as integrating the BSC or even the entire osmo-nitb onto the ARM/Linux processor inside the BTS hardware itself, creating a less than 500gram, 10W power consuming autonomous GSM network.

I'm going to stop marketing here, but I thought it is one of the major milestones for sysmoocm and thus for what I've spent way too much time on in recent months - and thus deserves to be mentioned here on this personal blog.

Syndicated 2012-05-19 02:00:00 from Harald Welte's blog