May 16, 2012

OsmocomSDR news feed: First 16 OsmoSDR boards available for developers

There are something like 16 units of OsmoSDR that we have produce and which are able to sell to interested developers.

However, as there are only 16 units right now, and as the firmware and host software is in a barely usable but incomplete state, we would like to make sure that those 16 units get sold to people who actually have an interest (and expect to have at least some time time!) to fix and improve the current shortcomings.

So if you want to be among the first 16, I suggest you contact me at Harald Welte <laforge@…> and include a short description of who you are (if you are not a Osmocom regular) as well as some incidcation that you are actually going to work on improving the code. If you already know an area that you'd like to work on, please state that, too.

The price will be 180 EUR incl. VAT (that's 151.26 EUR without), i.e. the same price as for the units that will later be sold openly.

I have put together a wiki page with the current status at OsmoSDR/Status to make you aware where we are and what is missing.

Thanks in advance for your willingness to be early users and help us to improve the codebase.

May 11, 2012

Boards assembled

May 08, 2012

OpenBSC news feed: Osmocom User Group Berlin Meeting on May 09

This is the announcement for the 3rd incarnation of our bi-weekly Osmocom Berlin meeting.

May 09, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

The schedule is as follows:

19:00 Introduction / Workshop on Osmocom SIMtrace (Kevin Redon)

Kevin will introduce SIM/USIM/UICC cards, present what SIMtrace is and how it works, as well as how to use it to trace communication between SIM card and phone.

20:00 Informal discussions

If you are interested to show up, feel free to do so. There is no registration required. If the initial part is not interesting to you, feel free to join us later at 20:00. The meeting is free as in "free beer", despite no actual free beer being around ;)

May 07, 2012

Harald "LaForge" Welte (Osmocom): Some follow-up on the Osmocom Berlin meetings

We've now had the first two incarnations of the Osmocom Berlin User Group Meeting. The start was great, and we had probably something around 10 attendees. Some were the usual suspects like the various Osmocom developers living in Berlin. But we also had a number of new people attending each of both of the meetings, which is good.

To my big surprise people are even flying in from other parts of Europe in order to be able to attend. Last time from Sweden, and for the next meeting some folks from the Netherlands have announced themselves.

To an even bigger surprise, the attendee from Sweden announced that he is working for an Ericsson research lab, and apparently they are using OsmocomBB quite a bit inside that lab. They think it's a great tool, and apparently nothing else with the same flexibility (i.e. full source code) is at their hands that can compete.

On the one hand it is surprising to see such a large traditional Telco supplier to start to use such amateur tools like OsmocomBB, which definitely have not had even a fraction of the testing (particularly with various operators in various countries) like the commercial protocol stacks.

On the other hand, if you think more about it, Ericsson is entirely a network equipment supplier today. They have spun off their baseband processor business to become part of ST-Ericsson, they have pulled out of Sony-Ericsson, sold their TEMS product line to Ascom and other bits and pieces to Tieto. So right now, if they need a MS-side protocol stack or engineering phones, they probably have to obtain what is available on the market. And that's unfortunately not all that great, as the products are either

• Measurement devices aimed at mostly L1 testing / QA (Racal, Agilent, Rohde-Schwarz)
• Trace mobiles primarily aimed at field testing (TEMS, Sagem OT) and while they provide traces they don't permit you to send arbitrary data or behave spec-incompliant
• Mobile Phone development platforms (Qualcomm, MTK, Infinenon, ...) which don't necessarily give you the full source code to the stack, and are only available if you actually intend to build a handset

So all in all, the more I think about it, it is actually not too surprising that they ended up with OsmocomBB. It's free (as in free beer) and they get the full source code with it. You need a lot of skills and time to get it running and find your way around how to use it, but I guess if you're working in cellular protocols and embedded systems, it's not that hard.

April 24, 2012

Dieter Spaar: A bit of 3G Layer-1

While experimenting with my Node-B, I had the need to generate a RACH message without having to use a phone. Such an approach can for example be used for performance testing of the Node-B receiver or evaluating the RACH handling capacity of the radio network (no, I don't call it RACH DoS ;-)

First a little bit of theory: The RACH in UMTS works different than in GSM, its not just about sending a single RACH burst. Because WCDMA is very sensitive to interference, the phones have to send with a transmit power as low as possible. For the RACH procedure this means that the phone starts to send a short RACH preamble with very low power and looks for the acknowledgement if the preamble has been received by the Node-B on the AICH (Access Indication Channel) channel. If the phone doesn't receive the acknowledgement, it increases the transmission power and resends the preamble. If there is the acknowledgement from the Node-B, the phone sends the actual RACH message. The RACH message itself is not just a few bits containing the access cause and a random reference like in GSM, it is a complete message. "RRC Connection Request" is used for accessing the network but other message can also be sent on the RACH channel (e.g. "Cell Update" which is besides other things used for indicating unrecoverable RLC errors. One can see this message frequently when starting to implement an RNC ;-).

Now where to get a RACH preamble and message without having to use a phone? I started to look at Agilent's Signal Studio for WCDMA which should be able to generate a RACH messages with user defined content which can be replayed with a signal generator. However even after lots of trials I never managed to generate a RACH message which can be properly decoded by the Node-B, only the RACH preamble is detected without errors but the RACH message itself just produces garbage and CRC errors.

So I started to write my own code to generate the RACH message. The relevant 3GPP specification for WCDMA FDD is TS 25.212 (Multiplexing and channel coding) and TS 25.213 (Spreading and Modulation). Basically the steps to create a RACH message requires adding a CRC to the message bits, Convolutional encoding, 1st Interleaving, Rate Matching, 2nd Interleaving, Spreading, Scrambling and finally Modulation. I and Q signal on the Uplink carry different things, Data is on the I signal, Control (pilot bits and transport format information) on the Q signal. Luckily the RACH message does not require any fancy multiplexing and rate matching of multiple transport channels on a physical radio channel. This can get really funny, especially if Turbo Coding is involved which results in multiple bit streams (systematic and parity bits) which are treated differently. After some trial-and-error and lots of experimenting and testing I was finally able to create a well formed signal of a RACH preamble and message which the Node-B can properly decode.

After that I also tried to decode the RACH message generated by Agilent's Signal Studio to find out why it didn't work. It seems that the wrong scrambling code sequence is used (the scrambling code number looks OK, but the offset into the code bits is wrong). I really wonder why no one noticed this problem with Signal Studio before or maybe I am just doing something wrong. Anyway, I can now use my own code to generate RACH messages. Maybe in the future I will also look into generating a signal which a phone will consider as valid signal of a 3G cell, this requires generating the P-CPICH (Primary Common Pilot Channel), P-SCH/S-SCH (Primary/Secondary Synchronization Channel) and P-CCPCH (Primary Common Control Physical Channel) carrying the BCH.

April 16, 2012

Dieter Spaar: 3G User Plane

Continuing with my Node-B experiments I started to implement handling the user plane. I can now do voice calls, video calls and data connections. Just to make it clear, those are the very first steps only without any optimisation for speed and far from being complete or ready for release. I consider it as the essential "building blocks" necessary for the next steps towards a small Open Source RNC.

So how does it work? One way to allocate a channel for user data is to modify the existing signalling channel by sending the RRC "Radio Bearer Setup" message to the phone and the NBAP "Radio Link Reconfiguration Prepare/Commit" messages to the Node-B. Besides being much more complex due to the number of possible parameters and options this is somehow comparable to TS 04.08 "Channel Mode Modify" and A-bis TS 08.58 "Mode Modify" in GSM. If the commands succeed the Node-B will allocate another UDP port for the User Plane data besides the existing UDP port for the Control Plane data (UDP ports because I use "Iub over IP" to talk with the Node-B).

The User Plane data are embedded in FP (Frame protocol, TS 25.427). For voice the data are the AMR class A, B and C bits. To ease testing with a single phone I use a loopback which simply sends the received uplink AMR class bits back to the downlink.

Signalling for a Video Call is very similar to a Voice call. The main difference is in the CC Setup message, the bearer capability indicates UDI (Unrestricted Digital Information) for Video. UDI is basically a 64 kbit/s channel which transports video according to the 3GPP umbrella protocol 3G-324M) for video telephony. Loopback is not as easy as for voice because first the four-way H.245 protocol handshake has to be completed to agree on communication parameters, after that the uplink video data can be resent to the downlink.

Although UMTS is generally much more complex than GSM/GPRS, handling of data connections is easier than for GPRS because there is no need for a PCU (Packet Control Unit) with all its complexity. There is the optional protocol PDCP (Packet Data Convergence Protocol, TS 25.323) on top of RLC which is used for things like header compression. But if you don't use it, you get the raw IP packets embedded inside RLC.

April 13, 2012

April 09, 2012

Harald "LaForge" Welte (Osmocom): Prototype smart card chips in DIL-40 case have arrived

Finally, the first samples of the smart card chip (for the Osmocom CardOS project) have arrived. As opposed to the final smart cards, this one has been packaged in a DIL case instead of the usual thin credit-card sized plastic. The reason for this is quite simple: This way lots of I/O pins for debugging as well as JTAG can be accessible during COS development.

Here you can see the first incarnation of a veroboard connected to an adapter pcb inside an Omnikey smart card reader:

After confirming it worked, I soldered the wires directly to the adapter PCB, as can be seen here:

There is already a real PCB design that is currently manufactured, i.e. in a week or so there will be a picture of a clean, professionally-produced/etched PCB with all of the prototype pins exported.

In terms of the COS, I haven't done much more work than compared to the last posting, mainly due to a large number of other projects. But we will get there...

Harald "LaForge" Welte (Electronics): Name that UART: April 2012

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: I'm going to post one picture every month about a UART that I found on embedded hardware. Unfortunately I don't have much to offer in terms of a reward for whoever finds the true solution ;)

In any case, every month there are devices that I'm looking into either out of my own interest, or because the work at gpl-violations.org requires it. In most of them, you can find a UART to get to the u-boot / Linux serial console.

So here is the device that I just took apart earlier today:

The location of the UART pads was obvious, after looking at the PCB for a very short time. The entire unpopulated U1 footprint appeared suspiciously like a UART level shifter for true RS232 voltage levels:

• You can see two signals going directly to a small unpopualted3-pin header
• There are two other signals coming from somewhere under the main SoC
• There are capacitors (C440, C441) directly connected to the U1 for the charge pump

April 04, 2012

David Burgess: The Terminal-State of the Telecom Industry?

April 03, 2012

OpenBSC news feed: Osmocom User Group Berlin

On April 11, 2012, the OsmoUserGroup/Berlin will have its inaugural meeting.

The idea is more or less in the spirit of Linux User Groups, who in turn have learned from Unix User Groups, etc: A regular meeting where users and developers of the specific software can meet, share their experience and code, and work together improving the project.

Whenever possible, there will be some formal talk in the first part of the meeting.

More information is available at OsmoUserGroup/Berlin.

Registration is not required. Just show up at CCCB on April 11 between 7 and 7.30 pm.

March 26, 2012

Harald "LaForge" Welte (Osmocom): h-online article covering OpenBTS and OpenBSC

You can find a 3-page article about OpenBTS, OpenBSC and related projects available from the h-online web site.

Harald "LaForge" Welte (Osmocom): OsmoDevCon 2012 is over...

We just finished the 4th and final day of the OsmoDevCon 2012. It contained four days of in-depth presentations and discussions related to Free Software communications systems, most notably OsmocomBB, OpenBSC, OpenBTS, OsmoNITB, SIMtrace, OsmoGMR, OsmoSDR, rtl-sdr and many more.

I think it was a great chance to make sure the key developers involved with those projects are up-to-date with what everyone else is hacking on. I was especially happy with the presentations of Holger's smalltalk implementation of certain GSM protocols/interfaces, and it seems my small informal Erlang intro has raised some interest.

If anything, the 4-day conference has shown that there is a massive amount of work going on in the various different projects, and that it has clearly grown beyond anything that a single person could still be involved in all the sub-projects.

Personally, I'm happy to see what has grown out of this "we have a BS-11, let's see what we can do with it" that Dieter and I started in 2008. Now we're no longer talking about BTS/A-bis/BSC, but about SS7, MSC, TCAP/MAP, SCCP, HLR, Erlang, smalltalk, DECT, SIM/USIM, COS, SDR, GMR/Thuraya, TETRA and more recently also femtocells as well as NodeBs.

In the spirit of that 2008 presentation Running your own GSM network using the BS-11, Dieter Spaar has now demonstrated his talk on Running your own UMTS network, using NSN or Ericsson NodeBs. I'm really excited to see where that will take us - despite the fact that due to the 5 MHz wide channels, it's pretty close to impossible to get the experimental spectrum licenses that most of us have been able to get in recent years for our work.

As an outlook, over the remaining year 2012, I see progress in the following areas:

• osmo-nitb will get a VLR/HLR split (async database access)
• we will build a stand-alone osmo-msc with A interface
• the signerl TCAP/MAP implementations will be used in production
• OsmoSDR firmware will be completed, the hardware will start shipping
• a new card operating system (OsmoCOS) will emerge
• a UMA gateway will be implemented
• a Free Software GPRS/EDGE PCU and RLC/MAC implementation will appear
• last but not least, sysmoBTS will start commercial shipment really soon now

I'd like to thank our host c-base for having us block their conference room for 4 days, as well as all attendees who have travelled from all parts of Europe, but even the United States and Russia to participate. There definitely will be another OsmoDevCon, though we don't know yet at which point in time.

March 18, 2012

OsmocomSDR news feed: Introducing RTL-SDR

While the OsmoSDR is still not available, some Osmocom team members (notably Steve Markgraf) have been hacking away on an alternative least-cost solution: rtl-sdr.

So what is rtl-sdr? It is a creative form of using consumer-grade DVB-T USB receivers, turning them into fully-fledged software defined radios.

Those DVB-T receivers supported by rtl-sdr are based on the Realtek RTL2832U chipset plus a tuner IC like the Elonics E4000.

The RTL2832U has some undocumented commands/registers, by which it can be placed into a mode where it simply forwards the unprocessed raw baseband samples (up to 2.8 MS/s 8-bit I+Q) via high-speed USB into the PC, where they are routed into gnuradio.

At a street price of about USD 20 to USD 25, they are undoubtedly the most capable low-cost SDR hardware that can be bought. So now there is really no more excuse for anyone to not learn gnuradio. You don't have to buy a USRP, not even a FCDP or an OsmoSDR: A USD 20 device is all that's needed for receiving signals like GSM, GMR, DECT, TETRA, APCO25 and many others.

Harald "LaForge" Welte (Osmocom): Using a cheap (USD 20) DVB-T USB stick as SDR receiver for (not only) gnuradio

Fellow Osmocom hacker Steve Markgraf has been working on what now seems to be the cheapest way to receive real-world radio signals for PC-based SDR like gnuradio: rtl-sdr. RTL refers to the RTL2832U chipset frequently used in such devices. It can be used to obtain 2.8 Ms/s of 8-bit I+Q samples.

Below is a picture (courtesy of Steve) how the hardware looks like:

March 16, 2012

Harald "LaForge" Welte (Osmocom): Osmocom GPS timing source with u-blox LEA6-T

Recently we have been looking for an inexpensive way to generate a high-accuracy clock source for E1 lines, as it is required by a number of classic BTSs that don't have a sufficiently accurate OCXO built-in.

Luckily, the Digium E1 cards like TE-410P have a timing connector, to which an 8.192 MHz signal can be injected. Unfortunately, there don't seem to be any OCXOs around for that frequency. That's where the u-blox LEA-6T comes into play: It has a configurable TIMEPULSE2 output that can generate any frequency up to 10 MHz. We use this in our board to generate 8.192 Mhz and want to feed that into the Digium card.

So all we had to do is build a small board that contains the module and connector for antenna input, clock output and the obligatory 2.5mm stereo jack for the OsmocomBB-style UART:

Thanks to Sylvain for doing the schematics/PCB design, and thanks to Pablo for writing the code to configurea and activate the 8.192MHz output.

Once the design is verified, the schematics + gerber will be available, as well as board from the sysmocom webshop.

March 15, 2012

David Burgess: Some Comments on Satellite Phones

(There is now a follow-up to this post that digs into some of the details of GMR-1 transmissions. The (in)security implications are stunning.)

David Burgess: GMR-1 Revisited

March 14, 2012

Harald "LaForge" Welte (GSM): Alcatel MTK phone UART pinout

The Alcatel OT-890D is a MT6573 based smartphone. It seems one of the UARTs is available on test pads as seen in this picture:

The voltage level is still 3.3V, so no fancy 1.8V gear is required.

During boot, the UART is first used at 19200 bps, where it prints the strings "MW01" and "MW02". I then switches to 115200 bps where it prints "READY", and finally switches to 921600 bps, where it seems to output some mixed binary/text messages containing AT commands and responses between AP and BP, as well as some debug information:

�Ue� � � T+CREG=2
�Ue�!�!�!T+CSQSQ=1
�Ue�!�!�!AT+CREG=2
�Uew�"w�"w�"SQSQ=1
'Ue"""      AT+EFUN=1
      SML: Load!_Ue""""""
                         SML: Load!hU("("("

I haven't yet investigated if the binary between the text is some standard HDLC framing or a TS 07.10 multiplex.

If anyone knows more about the boot process (MW01/MW02/READY) or the binary protocol, please let me know.

March 09, 2012

OsmocomGMR news feed: GMR-1 dissection merged in Wireshark mainline

All the current patches that were pending in the sylvain/gmr branch of our osmocom Wireshark tree have now been merged into the official trunk. Thanks to the Wireshark folks for reviewing them and merging them quickly.

What's supported :

• BCCH partial support (segment 1/2A/3A fully dissected)
• CCCH partial support (all messages ever seen on Thuraya are supported)
• RR partial support (all messages ever seen on Thuraya are supported)
• MM/CC forwarded to GSM dissectors and are mostly correct

The sylvain/gmr branch will now be removed but may re-appear in the future if new dissectors are written. Basically if we have new gmr stuff pending inclusion it'll be in that branch, and if the branch doesn't exist it just means the official trunk contains everything so far.

March 03, 2012

Kevin Redon: SFR statistics

Update (2012-04-22)

Here some updates:

• The feature is still available, and I got no reply. They even reworked the interface, so to be more square
• Every night the web interface is down (for technical reasons), but the ajax call still works (I think it’s more for practical reasons)



• The interface will only tell you the phone model when it’s compatible with the femtocell, but the underlying json response will always tell the model (if it’s an SFR subscriber)




• Previously the scraping script just saved the plain json response into a file, and the extraction script collected them. But beginning with 500 000 files, the extraction took hours because of the high disk IO. Now the script parses the response and directly saves it into a SQLite3 database
• It seems you don’t even need the femtocell option (even if it’s for free). You only need an SFR account, and just have to log in. The new script can do the log in for you, if you enter the credentials. Else you must provide a valid cookie
• Since a SQL database is used now, making statistics has become a lot easier. The new statistics will do the pie chart for you (using the pie script). Both are included, and you can reuse the pie script to make nice (vector) charts for whatever you want

Here the scripts/source code: sfr_phones_db.tar

And just for the fun: new statistics (based on 3.88% of all numbers, collected over the last 2 month).

Original (2012-03-03)

spark

It all began when I logged on the SFR customer portal, and there my phone was shown. This phone was my own, and not the one provided with the mobile subscription. How do they know which phone I use?
Well, every time your phone registers to a cell tower, it can send its IMEI (deliberately, or upon request). This IMEI reveals the manufacturer and model of the phone (the prefixes are registered), and uniquely identifies it.
And so SFR knows which phone their subscribers are using.
This is not something new, but it was the first time I saw an operator show this info to the customer.

Now, I also have a femtocell from this provider (you can request it for free), and I am allowed to add subscribers to the group of phones allowed to connect to the femtocell. SFR has to verify if it’s a SFR customer, and additionally tells if it’s compatible with the femtocell. Only 3G can connect to the device as it provides UMTS coverage. And this information is shown when trying to add a phone number. Even the phone model of the subscriber was shown (quite a privacy issue).

farming

Thus, I though I could put in any number, so to know if it’s an SFR number, and if the subscriber uses a 3G phone, an which one. But I don’t want to do this manually using their complicated website, when a script could do the job for me.

To find out how this feature works, first go to the specific section:

• path: Mon Espace Client > Gérer mes lignes > Ma ligne mobile > Offre et Options > Choisir de nouvelles options
• click: ESPACE CLIENT -> Gérer mes lignes -> Mon abonnement et mes options -> SFR FEMTO; Créer Mon groupe SFR Femto -> Modifier mes membres -> Ajouter un numéro mobile SFR
• URL: http://www.sfr.fr/espace-client/offre-mobile/selfcare-groupe/option-sfr-home-3g/modification/modifierNumero.action

Then simply start wireshark and sniff the HTTP traffic (they do not use HTTPS). There you can see that once you entered a phone number in the form, some AJAX script performs a request.
It very simply queries the following URL, with MSISDN being the phone number.

http://www.sfr.fr/espace-client/offre-mobile/selfcare-groupe/option-sfr-home-3g/souscription/jsonEligibilityFemto.action?msisdn=MSISDN

The server returns a json response with the relevant information: is it an SFR subscriber, is it femtocell compatible, and what is the phone model.

counting

I decided to use (abuse) this capability in order to make some statistics (with self-made pie charts):

• how many phone numbers are registered to SFR
• how many phone are 3G phones (implied from being femtocell compatible)
• what are the most used phone manufacturer and model

The (ruby) script uses wget to save the json responses, and only requires a valid cookie. The get this cookie, just log on the SFR customer portal and go to the page to add numbers to the femtocell group. You can export the cookie using Export Cookies (for Firefox).

In the beginning, the script randomly queried numbers in the range 06xxxxxxxx (100 millions possible numbers). It got 0.32% of the possible numbers between 2011-09-29 and 2011-10-05.

Here the results:

evolution

On 2012-03-02, 0.05% of possible numbers have been scanned again (randomly). The results are quite similar.

targeting

Later on, I found out phone number ranges where pre-allocated. In France, the ACERP is responsible for that (regulating telecommunications), and the list is available on their page.
Now instead of trying random numbers, it’s possible to use the known ranges. SFR has 35 prefixes in the 06xxxxxxxx range, with in total 27.8 millions possible numbers (out of 100 millions).
But there is a glitch. Since a few years, the subscribers are allowed to keep their number when switching operator. This is the so called “mobile number portability”. Thus some of the numbers with SFR prefixes are not SFR subscribers anymore, and SFR has subscribers with non SFR prefixes. This is not regulated by the ACERP and there is no public list. Only the operators themselves know which operator uses one of their numbers. 14.80% of SFR numbers do not have an SFR prefix (from the statistics from 2012-03-02), which is not really insignificant.

Out of the 27.8 millions numbers with SFR prefixes, 0.46% have been queried on 2012-03-03.

source

Obviously I can not provides the data collected, because of privacy reasons. Also, only the statistics have been kept (not all shown here), an the raw data deleted (I’m quite responsible, aren’t I?). But here are the scripts.

Finally, I don’t know how often the subscribers phone information are refreshed. One could find it out by trying, but I’m too lazy.

rules

Now the boring legal thoughts.

I contacted SFR, but that was really not an easy task. On the official contact page there is no e-mail address. You can only phone the customer service. It’s quite expensive, reserved for customers, French only, and I really don’t want to talk to a hot-line trying to explain I don’t have a problem with my product, but they have a privacy issue. There also is a forum, but you have to subscribe and the post will be public (we want to warn them only). Also, I’m not a friend of dead trees, don’t want to pay a 1€ stamp for a letter, and why should I provide them my postal address.
After some time (1 hour of clicking), I randomly found (using google, not their site) an e-mail address on the impress of the corporation site: contact[at]sfr.com. Sadly it is invalid (their mail server returns a unknown recipient error), as are root/admin/webmaster/postmaster.
Finally the mail successfully went to info[at]sfr.com, but even after one week I got absolutely no reply and the feature is still available.

On one hand, the corporations always tell us to warn them if we find a bug. But when we try to do so, it’s really hard to get in touch, and most of the time, as long as the bug is not public and does not cost them too much money, they simply do not care. This is not the first time this happens to me. Actually, I never got any reply until the bugs I reported got in the mainstream specialized press.

Now another question: is this work legal? This is a hard one. On one hand, scraping/harvesting is not really forbidden. All search engine do it (as long as they respect robot.txt). It’s on their website, which is available over the whole Internet.
On the other hand, you have to login in. This function is only available for customers (a friend). But then, it’s a service provided by the operator himself. They implemented and thought about it. It’s a feature, not a bug. The operator is responsible for its data, and making user data available to others is probably breaking some privacy laws.
Now about copyright. I extracted data from their website. Considering a website as a database is risky, but this feature is somehow connected to a real database. In the copyright laws, there is a section about databases, with different right. Extracting a database is less allowed. But the script is not really connected to it, merely to a simple interface, available as service on their website. Also, I did not keep or published the data. I just ran some statistics over it and erased them afterwards.
Finally, it’s a French website, but I’m not doing this from France (luckily I don’t live there). Which law applies to me? The French or the local one?

So coming back to the question: it’s a gray zone open for debates. But getting this statistics was a nice exercise with interesting results. How else would you know how much of the allocated numbers are used? how many have 3G phones? what are the main brand? … This is data normally only operators have and would never make available. I’m not even sure if they do such statistics or if it’s just data laying around. And I think I was quite responsible when handling it.

March 02, 2012

Harald "LaForge" Welte (Electronics): OsmoSDR status update

It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at that time, there was no FPGA code yet, and some hardware bugs still had to be resolved. Nonetheless, the e4k tuner driver could already be implemented and tuning was confirmed by looking at the analog i/q spectrum.

Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL code written by maintech.de. Ever since that, they dropped the ball again with me as I had been careless enough to volunteer for writing the firmware.

And that's what I did or at least tried to do for quite some time during the last two weeks. The main problem was that I didn't have much time. The second problem was that I never was able to get the SSC (synchronous serial controller) receive DMA working.

This was a really odd experience, as I've worked a lot with that very same SSC peripheral before, while writing firmware for the OpenPICC some 6 years ago. However, this was in an at91sam7s, where the SSC is interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller, capable of scatter-gather DMA and other fancy stuff.

Atmel has provided reference code that uses the SSC DMA in transmit mode (for a USB audio device playing back music via the Wolfson codec on the SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I set out to write code for DMA-based SSC receiver. And it never worked.

I actually wrote two independent implementations, one from scratch and the other based on Atmel reference code. Neither of them worked. It seemed to be a problem with the hardware hand-shaking between SSC and DMAC. The SSC was successfully receiving data, and that data could be read out from the CPU using a polling or IRQ based driver. But if you're running at something like 32 Mbps and don't have a FIFO, you desperately want to use DMA. When the DMA handshaking was turned off, the DMA code worked, but of course it read the same received word several thousand times before the next data arrived on the SSC.

In the end, I was actually convinced it must be a silicon bug. Until I thought well, maybe they just connected the flow controller to a different ID in Rx and Tx direction. Since there are only 16 such identifiers, it was relatively easy to brute-force all of them and see if it worked. And voila - using the identifier 4, it worked!

So what had happened? The Atmel-provided reference code contained a

 #define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3

In case anyone else is interested, a patch can be found at my at91lib git repository.

I filed a ticket with Atmel support, and they pointed out in fact there was a table with those identifiers somewhere in the early introductory chapters where you can see a brief summary of the features of each integrated peripheral. Unfortunately they use slightly different naming in that chapter and in the DMAC, so a full-text search also didn't find them. Neither is that table visible in the PDF index.

So about four man-days later it was finally working. Another day was spent on integrating it with the USB DMA for sending high-speed isochronous transfers over the bus into the PC. And ever since I'm happily receiving something like 500,000 or 1,000,000 samples / second from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or Windows, the Linux audio drivers don't make arbitrary restrictions in the sample rate. According to the USB Audio spec, the sample rate can be any 24bit number. So audio devices with 16.7 Ms/s are very much within the spec. I hope some of the other OS driver writers would take that to their heart.

One of the first captures can be found at this link, containing a bzip2ed wave file in S16LE format Stereo (I/Q). It contains a FM audio signal transmitted using a small pocket-sized FM transmitter.

There is no I/Q DC offset calibration yet, but once that is done we're probably able to finally put the design into production.

Harald "LaForge" Welte (Osmocom): The next project on the horizon: A Free Software CardOS

Now that we have a 100% free software GSM protocol stack and baseband firmware for the network and mobile phone side, the only remaining proprietary part is the SIM card. And what is a SIM card? It's a small embedded computer / SoC with integrated flash + RAM.

Once again, like in many other areas of the telecommunications industry, development of Free Software has been hampered by lack of available register-level hardware documentation. Without such information, how should you be able to program? Hardware without such documentation is an insult to every software developer.

The next problem is that typically, the Card Operating System (COS) is written into mask ROM of the smartcard SoC. Making such a mask is quite expensive, and it means that for every software version, different silicon will have to be produced. So unless you are going to have millions of units in quantity, it is unlikely that it would make economic sense.

However, in recent years, purely flash based smartcard chips have been available and getting less and less expensive. However, none of them (like the Atmel AT90SC7272 or similar devices) have freely available documentation. Furthermore, availability on the open market is somewhat of a problem, mainly because they have been used extensively by people cracking encrypted satellite TV channels. In recent years, the smartcard industry is trying hard to cut any kind of supply to that group of users.

However, luckily, we now see small/independent chip design houses in China picking up and producing their own smartcard chips. They are not only cheaper, but they simply hand out the documentation to anyone who asks them. No questions asked, no NDA required. Welcome to the promised land! That's what Free Software developers like:

• Free access to documentation without any confidentiality agreements
• development samples available at the same price as quantity pricing later on
• inexpensive development hardware with JTAG access
• reference source code provided without NDA
• they are happy that somebody wants to develop for their hardware

As you can see, I am quite enthusiastic about this. I like this no-bullshit approach. No stupid marketing and sales droids who charge ridiculous fees for proprietary development tools that are inflexible and force developers to use one particular OS/IDE/toolchain.

I'm not sure how much time there will be, given the multitude of other projects that are all asking for attention. However, I think this is a chance that the Free Software community doesn't get every day. Let's hope some other people like bare iron programming in small embedded systems can get excited and we can create a FOSS COS. It doesn't have to be something serious. Something quite simple would be sufficient for the beginning. I'm not thinking of EAL4+ certification, multiple channels and public key crypto. SIM/USIM cards are simple, they just require a bit of filesystem read/write operations plus authentication. And luckily, SIM toolkit development doesn't have to be done in Java this way, either ;)

March 01, 2012

Harald "LaForge" Welte (GSM): More research into the Motorola Horizon macro and Mo-bis

Once upon a time there was an Americans company called Motorola, and they decided to implement GSM. Unfortunately they decided to deviate significantly from the specification and implement their own proprietary back-haul protocol between BTS and BSC, called Mo-bis. It replaces the standardized A-bis interface.

Today, There are plenty of phased-out Motorola Horizon / Horizon II macro BTSs that have been phased out. Basically you can get them for scrap value, which makes them an ideal target for GSM enthusiasts willing to run a single-cell network with little investment. So while there are actually people who are interested in operating a power-consuming device roughly the size of a washing machine in their home/office - they are normally not interested in running a 19" rack sized Motorola BSC with it. Also, the BSCs are much less frequently to be found compared to the BTS.

So it would be great to support Mo-bis from within OpenBSC. A couple of brave young men have set out to try the seemingly impossible. There's absolutely zero documentation available on that protocol, and no wireshark support either. However, the University of Brno (Czech) has a functional Motorola BTS + BSC setup, and I was able to obtain protocol traces from them and actually experiment with the equipment in their lab.

The entire Motorola GSM architecture seems to be over-engineered without end. Basically you are looking at a distributed computer from the early 1990ies. Lots of processor cards (m68k, ppc) interconnected by HDLC links on top of synchronous 2Mbps links with 64k timeslots. Those links are available e.g. on the backplane of the BTS as a TDM highway. So basically even inside the BTS, the individual processors talk over E1 to each other. In the BSC, there is a token ring based LAN between some of the cards instead. And the MCUF in the BTS even supports to transport those proprietary inter-cpu links via fiber optic (!).

Each processor has a 16bit identifier by which it can be addressed in form of physical addresses. Individual processes on the processors have fixed process identifiers, and they allocate a variety of mailboxes in which they can receive messages from remote processors. There are routing functions at intermediate notes.

So any process on any processor card can send messages to any mailbox of any other process on any other processor, independent of its physical location (locally at the BTS, or at the remote BSC, or even at remote BTSs).

Besides physical addresses, there are also functional addresses. Thos addresses are used particularly to support fail-over. Every board in a BTS and BSC can be fully redundant, and if you use physical addresses, you would address one of the two redundant boards. Using functional addresses, you address the function they both can perform, and some routing magic will make sure it ends up at the current active node in the pair.

There are multiple processors in every TRX, and a couple of processors for each BTS, processors in the E1 line cards, etc. Now speaking of the actual Mo-bis interface: It seems to be a weird mixture between 08.58 (RSL) and 08.08 (BSSAP/BSSMAP). However, after staring at the messages sufficiently long, I have been able to write a more or less complete wireshark dissector for them. Radio Channel Activation (RACH/IMM.ASS) are for example handled directly inside the BTS, they don't exist as transactions on the Mo-bis like they do in A-bis.

So implementing the actual location update / MO+MT voice call and SMS related transactions is actually not all that hard. What makes things really difficult is the way the BTS is initialized at startup. Basically what resembles the OML part of standardized A-bis.

There is a lot of low-level management and bring-up of the individual processes and boards, and the download of a large 500 kByte-sized BLOB simply called database. This binary database contains literally hundreds of configuration parameters for the BTS and its neighbors. It also contains sophisticated configuration of the message routers, the switching/multiplexing of 64k timeslots on the various links, information on redundant paths within the back-haul network, etc.

Interestingly, using the password combination 3beatles and 4stooges on any of the serial consoles of the BTS or BSC, you can enter into a "god-mode" which permits you to enter the executive monitor (EMON). The executive is the operating system they run on both m68k and ppc processors. It provides access to something like a syslog of messages from the various processes, and you can manually generate messages that are to be sent to mailboxes of processes. You can inspect the object table (application programs an databases), read/write to PCMCIA flash cards, read and write to logical and physical memory, inspect CPU and I/O usage and much more. In fact, the integrated Code Object Manager (COM) even allows the processors to synchronize their code versions and remotely boot other CPUS via HDLC channels.

For a communications system geek like myself, it's extremely fascinating to see such a sophisticated and versatile system. I only wonder why on earth somebody would come up with something as complex, only to connect a couple of BTSs to a BSC. Thus, the only logical explanation is that Motorola has developed this distributed proprietary computing system way before they went into GSM, and they probably just recycled it as it already existed.

If anyone knows more about the history of this, I would be excited to hear about it. It literally feels like being an archaeologist. Analyzing ancient technology from our forefathers. But then, it only is 20 odd years old. The only time I had a similar feeling was when I briefly came in touch with IBM mainframes in 2001 and looking at IBMs SNA protocol stack.

February 24, 2012

OpenSIGTRAN news feed: OpenSigtran project started. Welcome!

For the last 15 years I was accustomed to use my own hardware and SS7 stack 
for various telecom projects(*).

Recently I was involved into building MVNO and came across Mobicents 
SS7 stack in Java.. and found out that there was no cost-effective ss7 solution 
capable of operating with high payload ;)
 

So, new open source project starts. 
Software will be open sourced, and hardware will not be expensive.
 

The board will internally convert several SS7 links into SIGTRAN M3UA. 
It has 2 G.703 E1/T1 and 2 100M Ethernet jacks.
Later on media support will be available.
Prototype is shown below.
 

Currently: 
– SS7 stack (and FPGA schematics) are ready and well tested
– new board with Xilinx Spartan6 FPGA is expected to be available before summer. 
  Now 100% software compatible board exists, developed 6 years ago with Spartan2
– MTP2 must be modified to interface the new board
 

OpenSigtran homepage is http://opensigtran.org 
Pictures and stories are available.
I'll appreciate any feedback. You are welcomed. 

(*) Project list can be found at http://telecomequipment.narod.ru/en

February 19, 2012

David Burgess: The Man Burns in 202 Days

For those who have not heard, the Burning Man ticket situation for 2012 is a real mess. This mess might affect our plans for the BRC test network this year. We'll just have to see what happens over the next three months.

February 02, 2012

OsmocomGMR news feed: Osmo-GMR now supports A5-GMR-1 cipher

Osmo-GMR now has support for cipher stream generation. This allows to see past the CIPHER MODE COMMAND in the examples (I will put the key along with the demo files soon).

You can see the actual code in the git :  http://cgit.osmocom.org/cgit/osmo-gmr/commit/?id=c70e5208d5a0daa9b3ff77c28f54d97f549d90f2

The algorithm was re-implemented by the Osmo-GMR team based on the reversing work done at the University of Bochum by a team comprised of Benedikt Driessen, Ralf Hund, Carsten Willems, Christof Paar, and Thorsten Holz. The Osmo-GMR team actually contributed in the late stages of this work by providing real world captures to validate the reversed algorithm and the attacks.

Dieter Spaar: Running your own Node-B

Its now nearly 3 and a half year ago that I wrote the first "Proof-of-Concept" code to get the Siemens BS-11 GSM Basestation up and running. So I think it was time to start with 3G, now that LTE is being actively deployed. You also can sometimes find reasonable priced, used Node-Bs which makes getting access to the equipment possible. A Node-B is the 3G equivalent of a GSM BTS.

So I spent quite a lot of time spread of several months to get a Node-B up and running. Compared with the BS-11 this was a lot more difficult and required much more time. Of course the Air Interface is completely different, in my case I looked at WCDMA FDD so far, there a few more standards used in other parts of the world. Then you have to deal with a huge, different specification, the most important when dealing with a Node-B are NBAP (TS 25.433) and RRC (TS 25.331), around 3000 pages in total. NBAP, the Node-B Application Part, is used to configure the Node-B and do things like creating Radio Links (communication channels) to the phone. RRC, the Radio Resource Control, is the Layer-3 protocol for the control plane between the phone and the access network. It is responsible for accessing the network, setting up and releasing connections or paging a phone. Both NBAP and RRC make use of ASN.1 which makes things not necessarily easier ;-) There are a few more protocols on the lower layers involved like MAC (TS 25.321), RLC (TS 25.322) and FP (TS 25.435 and TS 25.427).

The Node-Bs I used can run "Iub over IP" (Iub is the interface between the Node-B and the RNC, similar to Abis in GSM between the BTS and BSC). Originally Iub is based on ATM which runs over E1/T1 or similar lines with higher data rates. However "Iub over ATM" adds a few more protocol layers for dealing with ATM and I really wanted to avoid this additional complexity. Not all Node-Bs can automatically do "Iub over IP", usually it requires an additional hardware option (interface card). When using "Iub over IP" you have to deal with protocols like UDP and SCTP which are much more convenient.

The current status is a very minimal implementation of something like an RNC to run the Node-B so that a phone can register on the network and do simple things like SMS on the control plane. No user plane like speech or data yet, but this is the next steps I plan to do. The code is not yet public but it will be when it gets more evolved.

There is still a lot left to research and experiment with. For example I haven't looked at things like HSPA yet, I completely ignore handover to other cells as there is only one cell in my experimental setup. So I am sure 3G will give a few more years of a very interesting field to play with before looking at LTE ;-)

January 30, 2012

OsmocomGMR news feed: Lecture on cryptoanalysis of GMR-1 and GMR-2 ciphers

On February 2nd, researchers Be­ne­dikt Dries­sen und Ralf Hund of the University of Bochum will report on their analysis of the GMR-1 and GMR-2 ciphers.

According to the  abstract, the cipher used in GMR-1 and thus Thuraya is more or less the same than GSM's A5/2, and can be broken at similar complexity (i.e. almost none).

January 28, 2012

OsmocomBB news feed: OsmocomBB RSSI monitor firmware

OsmocomBB team member Andreas Eversberg has been working on a new RSSI monitor firmware application within OsmocomBB.

Using this firmware, it is possible to monitor the RSSI of individual ARFCNs or even the entire spectrum.

Depending on the hardware capabilities (e.g. Hardware/FilterReplacement), it is also possible to measure the uplink RSSI.

More details are available at rssi.bin.

The current status of this firmware is available from the "laforge/monitor" branch in git, but is expected to be merged soon into master.

Harald "LaForge" Welte (GSM): New OsmocomBB RSSI monitor firmware

Jolly has been hacking up a nice new RSSI monitoring firmware application for OsmocomBB.

I let the pictures speak for themselves:

I really hope this trend continues and we'll get some actual user interface in OsmocomBB at some point this year..

January 25, 2012

Harald "LaForge" Welte (GSM): OP25 project joins hosting on osmocom.org

Some days ago, I noticed that the famous OP25 project (a Free Software implementation of the APCO25 system, a digital trunked radio system) was no longer reachable on-line. It seems they were running this on a desktop PC in a university. As nobody in the project still seems to be at that university, a change in the network configuration had accidentally rendered the website unreachable.

After some quick e-mails, I offered to host them within the osmocom.org family of Free Software Projects for mobile communications. This is when op25.osmocom.org was created, and a full-site backup uploaded + installed.

I'm really happy that we were able to do a small part to help to make sure this valuable project remains accessible to interested parties in the signal processing and mobile communications field.

Harald "LaForge" Welte (Electronics): First osmo-nvs-gps evaluation boards soldered

At the osmocom project, we recently discovered the most interesting NVS NV08C-CSM module. It not only is a superb GPS receiver, but it includes GALILEO and GLONASS receivers, too. However, it's only available as an industry module, or as an expensive (700 EUR or so) evaluation kit.

Given the cheap PCB prototyping service at seeedstudio, I thought I'd spend an afternoon creating the schematics and PCB layout for an evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style 2.5mm jacks, so they can be used with the T191 cables. I have the feeling this 2.5mm jack is becoming a new standard for low-voltage RS232 links ;)

Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch header, connects to an external antenna via a MCX socket and has an optional footprint for a CR2032 battery on the bottom side.

So far, the board seems to be working fine. If there is interest in the bare PCB itself (without components!), please send me an e-mail. Depending on the amount of interest we might add it to the sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

January 14, 2012

Harald "LaForge" Welte (Electronics): First assembled prototypes of osmo-e1-xcvr

I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver board, which is going to be used for experimentally interfacing such a TDM line with microcontroller and/or FPGA. The name of this board is osmo-e1-xcvr.

The first prototype PCBs have arrived yesterday, and despite lots of other more important work I couldn't resist but to actually solder some of the units. The result can be seen here:

I don't have time to do anything beyond very basic testing right now, but so far the boards seem to be doing fine. Now we need a driver for the transceiver chip, and connect its control interface over SPI to some microcontroller (likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up at the SSC peripheral of the controller.

January 10, 2012

Harald "LaForge" Welte (Electronics): OsmoSDR status update

It's already two weeks since my last post mentioning OsmoSDR only very briefly. By now, OsmoSDR is fully public and you can read all about it on the http://sdr.osmocom.org/ website.

Specifically, the website includes Schematics, and one of my colorful block diagrams. I am a text guy and really hate to work with graphics, but the block diagram of the Calypso has helped a lot in the context of making people understand OsmocomBB, so I tried again for OsmoSDR:

So as you can see, it is a very simple, straight-forward design with a chip tuner, direct I/Q down-conversion, ADC for differential I and Q signals as well as a small FPGA for basic filtering and serial format conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high speed USB).

And yes, it's receive only. However, it has a stacking connector for later addition of a transmit daughter-board which may eventually follow later in 2012.

So what is this OsmoSDR going to be used for? Well, for receiving any kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz, untested). We don't build it for a specific application, but we simply thought that for many applications a member of the USRP family is expensive overkill, and the FCDP has this arbitrary restriction at 96 kHz sampling frequency.

Please note that while I may be the only OsmoSDR developer that blogs about this project, it is very much a team effort and I'm only a minor part of that team. Apart from selecting the SAM3U, writing firmware and drivers for it as well as some discussions early on in the project, I didn't have any involvement in the Hardware design. Those credits go to Christian Daniel and Stefan Reimann.

So where do we stand? There are 5 prototypes of the first generation, they look like this:

There are some smaller hardware issues that were easy to work around, but one bigger problem related to the fact that the Si570 programmable oscillator output levels didn't match quite with what the FPGA clock input requires.

There will be a second generation board fixing this and other problems, and hopefully we'll see some progress in the weeks to come.

Firmware-wise, the code is currently scattered over a couple of different repositories, but I'm going to consolidate that soon. If you've worked with OpenPCD or SIMtrace, you will find some similarities: We split the flash of the controller into two partitions: One for the DFU bootloader, and one for the application code. You can then use the USB DFU (Device Firmware Upgrade) standard to quickly update the actual firmware of the device, without having to resort to jumpers or un-plugging and re-plugging of the hardware.

This also meant that I had to re-implement the old sam7dfu code for the SAM3U, which has considerable differences in the USB peripheral, cpu core, board startup code, etc. So it's really a reimplementation than a port. The good news is that I tried to make it as general as possible and integrate it with at91lib, Atmels reference code. So it should be easier to use it with other Atmel SoCs like the sam3s which I want to use e.g. in SIMtrace v2.

December 31, 2011

OsmocomSDR news feed: OsmoSDR hardware verification at 28C3

At  28c3, the OsmoSDR team was busy verifying the hardware design on the first prototypes.

The result can be summarized as:

• SAM3U is working, enumerates on USB and can be programmed via SAM-BA
• E4K tuner driver is working
• Si570 driver is working
• FPGA can be flashed via JTAG bit-banging from SAM3U
• FPGA and SAM3U can speak via SPI

However, there are at least two bugs:

• USB socket footprint pin-out was mirrored
• clock output level of Si570 doesn't match FPGA clock input specs (amplitude too low)

The issues have been worked around, and firmware + FPGA development has made progress.

OsmocomSDR news feed: About OsmocomSDR

This is the blog of the OsmoSDR project, a small-size, low-cost Software Defined Radio hardware/firmware project.

OsmocomGMR news feed: Video and Slides of Sylvain's 28C3 GMR talk

OsmocomGMR main author Sylvain Munaut has given a presentation about the GMR-1 standard and the OsmocomGMR software at the 2011 annual CCC conference (28C3).

It is a great introduction into the topic, and a recommended read/view for everyone wanting to experiment with our OsmocomGMR software.

The slides are available from  http://events.ccc.de/congress/2011/Fahrplan/attachments/2027_28c3_introducing_osmocom_gmr.pdf

The video is available from  http://mirror.fem-net.de/CCC/28C3/mp4-h264-HQ/28c3-4688-en-introducing_osmo_gmr_h264.mp4

December 29, 2011

David Burgess: UMTS: Truly, you have a dizzying intellect

December 23, 2011

Harald "LaForge" Welte (Electronics): More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bank

I'm currently quite excited to be doing more bare iron programming as well as actual electrical engineering work again.

There's actually not just one project I'm working on, but a variety of them:

• OsmoSDR - an upcoming small form-factor, inexpensive USB SDR. Not big and expensive like USRP or real "professional" solutions, but also not as weak as the ultra-narrow-band funcube dongle. I wasn't involved in the hardware design, but have volunteered to take care of the firmware development for the Atmel SAM3U micro-controller inside.
• osmo-e1-xcvr - a relatively simple circuit board containing the magnetics, LIU, clock generation and transceiver for E1/T1/J1 lines. The idea here is to have a solution for the analog part, as well as HDB3/B8ZS/AMI encoding, which can then be attached to any FPGA, CPLD or micro-controller development board. It exposes SPI for controlling the transceiver, and a synchronous serial bit-stream for Rx and Tx.
• unnamed sim-bank project - here the goal is to find a cheap solution to attach a large number of SIM cards to either a PC or directly to Ethernet. This can be very useful for testing, where you host your sim cards in a centralized location and can borrow them to remote users/devices over TCP/IP. There are commercial devices available for this, but they are quite expensive (like 1700 USD for 32 card device) and intended to be used with some proprietary windows software (who wants that?!?).

In the latter two projects I'm also doing the component selection, schematics design and PCB layout. One project with KiCAD, the other in EAGLE, as I really want to get first-hand experience of the usability of Free vs. proprietary EDA tools. I'd love to also evaluate Altium Designer, but they are still windows-only, and that would just make life way too difficult for me.

The projects will be duly announced soon, and they are all intended to be Open Hardware designs with Free Software. We'll probably also make all of them available at shop.sysmocom.de, too.

December 04, 2011

OpenBSC news feed: Introducing the Osmocom Continous Integration Setup

The Osmocom project has gained a  Jenkins setup that will build the various parts of Osmocom after each change. As part of this setup we have enabled automatically executing tests in libosmocore as part of the make distcheck command, it has been extended to the cellmgr_ng and hopefully will be used in all of our projects in the near future.

It is easy to add new tests and details can be found in  this email, an example of integrating test execution with GNU automake can be seen  here.

November 04, 2011

OsmocomDECT news feed: Linux 3.1 merged, P640j MAC/DLC/NWK layer support

I've merged the DECT tree with the Linux 3.1 release and pushed out experimental support for P640j (Wideband) in the MAC/DLC/NWK layers. Besides the kernel, libnl and libdect need to be rebuilt (Build instructions).

Asterisk wideband support is still unfinished and chan_dect will currently not build cleanly, only update if you intend to work on chan_dect yourself or want to play with wideband using the libdect example code.

October 17, 2011

Harald "LaForge" Welte (GSM): GSM Security Training at DeepSec

Dieter Spaar and I will be holding yet another GSM security training on November 15/16 at this years DeepSec conference in Vienna.

We have been giving a series of successful GSM Security trainings in-house at various operators, as well as at a variety of conferences during the last couple of years. If you want to beef up your knowledge on the detailed inner workings of mobile networks, with a specific focus on security related aspects, this training might be a great opportunity.

You can register here. Unfortunately the Early Bird discount has already expired, but you still have a chance to book before November 2nd, after which a late booking fee will apply.

October 16, 2011

OsmocomBB news feed: First Osmocom GMR code release

As some of the readers may already know, a couple of Osmocom developers have been working on a new sub-project:  OsmocomGMR.

The primary goal of this project is to provide a reusable and clean implementation of the various layers of GMR-1.

What is GMR-1 ? Well, it stands for "GEO Mobile Radio" and it's a set of specifications describing a satellite based mobile phone network heavily inspired from GSM. One of the major commercial operators of GMR-1 technology is "Thuraya", providing coverage over Europe/Africa/Asia/Australia?.

So far the implementation focused on the lowest layers:

• Physical layer with FCCH sync and demodulation support for pi4-CBPSK and pi4-CQPSK bursts.
• Channel coding layer (scrambling/puncturing/convolutional coding/crc/interleaving/...)

And some ancillary tools to exploit those:

• A good capture tool to listen to particular ARFCN(s) and channelize them properly
• Wireshark support (BCCH only so far)

The first 'demo application' using all of the above provides functionalities similar to what airprobe is for GSM: An air interface protocol analyzer that goes all the way from capturing data off-the-air to sending packets to wireshark for analysis. Limited to BCCH only currently but this will evolve with time.

Development was mainly done by Sylvain Munaut, with help from Dimitri Stolnikov (early signal captures and his great capture tool), Harald Welte (initiating the project) and Steve Markgraf (testing different setup and antenna ideas).

If you'd like to know more, you are encourated to read the  wiki and join the  mailing list

Harald "LaForge" Welte (GSM): First OsmocomGMR code release

The Omsocom project announces the first code release of the Omsocom project announces the first code release of the Omsocom project announces the first code release of the Omsocom project announces the first code release of the OsmocomGMR project. GMR is Geo Mobile Radio, the specifications for (among others) the Thuraya satellite telephone network.

For more details see the OsmocomGMR announcement.

I still remember some years ago, when Dieter and I were first working on some code to implement the GSM protocols, which later ended up becoming OpenBSC. A number of other developers joined the project ever since, and we have a wide user base, from individuals over academia up to commercial deployments. Next we did GRPS, which was another journey into a new world. While OsmoSGSN still has some bugs here and there, it has come a long way ever since.

In December 2010 at 27C3 I had this crazy idea of looking into yet another communications system (TETRA). Just one week of coding later, the first working code emerged and later became OsmocomTETRA. Again, history repeated itself and what was started by one person became a collaborative effort in very short time.

Finally, in July 2011, I thought it would be time for yet another communications system: ETSI GMR, used by Thuraya. This time I was too busy to actually write any code, but I just read specifications, found a supplier for some equipment and got some fellow Osmocom developers interested in it. For weeks, the IRC channel was flooded with daily reports about progress, new measurements/traces that had been made and about new code that had been written. About three months later, the code is capable of demodulating, decoding, de-interleaving, and it can give you a BCCH protocol trace in wirshark.

With this pace of progess, I wonder where we might be in yet another one or two years. At least on my personal agenda are the following items:

• Finish Erlang TCAP + MAP implementation, which will allow us to implement a true HLR/AUC and finally a new MSC that can interoperate with GSM/3G core networks
• Integrate OpenBSC and OpenBTS, especially now that we already have the BTS-side A-bis implementation as part of osmo-bts
• Get funding to implement a GPRS/EDGE PCU, enabling osmo-bts to talk to OsmoSGSN
• Work on some hardware+software interface that allows us to use the Motorola Horizon Macro BTS with OpenBSC, or at least their TRXs (called CTU) with osmo-bts
• Implement a UMA/GAN gateway (for UMA capable phones and femtocells)
• Support IuCS/IuPS from our MSC and SGSN for 3G Femtocells
• Complete the SIMtrace firmware/software to do full MITM and SIM card emulation
• Work on automated regression testing for osmo-bts, OpenBSC, OsmoSGSN and all other GSM related Osmocom components.
• Continue the excellent work that has been done on supporting MTK chipsets from OsmocomBB at some point

At least now you know there is never any reason to be bored. If you have time and are interested in helping with implementing any of this stuff, let me know.

October 13, 2011

Holger "zecke" Freyther: Creating a small GUI for the SIMtrace application

Earlier this year I created a Hardware company with a friend to supply to our GSM community and beyond. One of our first products is the SIMtrace Hardware (CC Licensed, actually it should work with any Smartcard). Today I had to wait a bit and decided to convert the CLI application that talks to the firmware to a GUI application. I did this by running the CLI part in a QThread and using QMetaObject::invokeMethod to callback to my GUI.

I started off creating the Qt application with VIM and a browser to help me to remember some function names. After a while I had enough of this and used Qt Creator and enjoyed the auto completion, it had no problem reading our C header files of libosmocore and provided auto completion for these too. Once again I am amazed how nice Qt Creator is and how little code I needed to create the below.

From October 13, 2011

September 25, 2011

David Burgess: Burning Man 2011 - Yes we were there.

September 24, 2011

Holger "zecke" Freyther: GNU Smalltalk deployment with images and image resumption

Once up on a time I was sitting in a cold hall at the Barcelona exhibition ground, a power outage has taken down several DVB-H platforms (racks consisting of servers, streamers, RF equipment...) and once power was restored red LEDs were blinking, systems not coming up automatically, hordes of engineers trying to boot the right kernel, trying to remember the multicast routes they had typed in by hand, chaos, hectic. It was interesting to witness that as we could lay back, continue with our work, as our platform was configured to come up automatically and it did.

One has to assume that stuff breaks, software, disk, RAM, CPU, power supply, anything. The only answer to that is be prepared, build your software to deal with failure (or nicely try to restart), make sure all systems start automatically, have backups, have a plan.

For my GSM (telephony) in Smalltalk components I didn't do that yet, mostly because my code was not very mature, I was still building up the trust relationship and so my deployment consisted of manually running GNU screen, then GNU Smalltalk, manually loading my code, starting things up. It was about time to correct that.

The tool of choice is the gst-remote application, it will run a GNU Smalltalk image, it can daemonize and it will listen for input from other systems. While moving to this deployment my fellow Smalltalkers were kind enough to fix some bugs on the way. There was an issue of gst-remote exiting when saving an image, the Delay class not functioning properly on resume, the wrong FileDescriptors being closed on image resumption. It is very nice to get help that fast!

My deployment now consists of building GNU Smalltalk packages, having a Smalltalk script to load the package and call start method of that package followed by taking a snapshot and exiting. I can then resume the image and if the software is prepared to deal with image resumption it will work.


Eval [
| name image |
name := Smalltalk arguments first.
image := Smalltalk arguments second.

(PackageLoader packageAt: name)
fileIn;
start.
ObjectMemory
snapshot: image;
quit.
]


September 18, 2011

Harald "LaForge" Welte (GSM): 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.

August 28, 2011

Holger "zecke" Freyther: shop for SIMtrace

The WebShop for the SIMtrace hardware can be found here. We are using a CA-Cert signed SSL certificate and your browser vendor might not like it.

Setting up, or mostly modifying the webshop was my first encounter with rails. In some ways it is a great framework, in others with a Smalltalk background there are some tears in my eyes. This is using spreecommerce because I wanted something that is not done in PHP and is not following the OpenCore business model.

The manual of spreecommerce is actually great from an engineering point of view, they describe the concepts, the models and how to modify it. But they are bit short on setting it up. There are some config options where no Graphical way to change them exists yet. So it is best to look into the app_configuration.rb of spree_core, e.g. to modify the default country.

There are still some bits that I would like to change, the code for my modification can be found on gitorious.

August 24, 2011

OpenBSC news feed: Announcing libosmo-abis

We have finally split the low-level A-bis access routines into a separate library called libosmo-abis. This allows us to re-use the code in a variety of projects outside OpenBSC, such as OsmoBTS.

However, this also means there is now one additional dependency that you need in order to build OpenBSC. However, it should be a simple autoreconf -i && ./configure && make install to build.

More information and tarballs can be found at libosmo-abis.

August 22, 2011

Holger "zecke" Freyther: Going down the Sangoma rabbit hole

I ended up needing to configure FreeSWITCH to use a Sangoma ISDN card. At first we were foolish and used the setup script to install libraries into our system.

Cleaning up

Second attempt with building packages

First attempt with FreeSWITCH

Second attempt with FreeSWITCH

ISDN libraries

Third attempt with FreeSWITCH

Summary

August 20, 2011

OpenBSC news feed: Introducing doxygen-generated API documentation

For quite some time there has been a distinct lack of API documentation regarding the various Osmocom sub-projects.

Starting with libosmocore/libosmogsm, we are introducing doxygen-generated API reference documentation. You can see the first results at the following pages:

•  http://www.osmocom.org/doc/libosmocore/latest/html/
•  http://www.osmocom.org/doc/libosmogsm/latest/html/
•  http://www.osmocom.org/doc/libosmovty/latest/html/
•  http://www.osmocom.org/doc/libosmocodec/latest/html/

Feel free to help us documenting more code in the various libraries, including libosmo-sccp, libosmo-abis, etc. Patches are always welcome at our mailing lists.

August 16, 2011

Harald "LaForge" Welte (GSM): 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

July 22, 2011

OsmocomDECT news feed: P640j/wideband support

I've pushed out P640j/wideband support, so far only for the 1442x firmware, the upper layers still need a bit of work. P640j can only be enabled if the PCMCIA driver is deselected and requires a firmware rebuild. I'd appreciate feedback whether things are still working properly on the PCMCIA devices.

OsmocomDECT news feed: Linux 3.0 merged

I've merged the DECT tree with the Linux 3.0 release. P640j/Wideband support will also be pushed out soon.

Harald "LaForge" Welte (GSM): 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.

July 14, 2011

Harald "LaForge" Welte (GSM): 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.

July 12, 2011

OpenBSC news feed: Introducing the osmo-bts project

For quite some time we've been hacking away on a project called osmo-bts.

You can find it source code as usual on git.osmocom.org, for occasional web browsing we offer  cgit access.

osmo-bts is a BTS-side Layer3 and Layer2 protocol implementation, including Abis/IP, TS 08.58 RSL, TS 12.21 OML, TS 04.06 LAPDm and various other bits and pieces required to run a BTS.

Specifcally, it does not include a GSM Um Layer1. Rather, the idea is to port osmo-bts to a variety of L1 implementations.

So far, hardware support only exists for an upcoming BTS product which is not available yet, the sysmocom femtobts. However, there is active work being done un hacking some  OsmocomBB phones into using them as a BTS, as well as support for other L1/hardware, too.

We are also planning to implement a 'virtual layer1', that can be used to run a BTS without any radio layer, interfacing the OsmocomBB stack via TCP/IP for netwokr simulation and software testing.

OpenBSC news feed: German podcast featuring OpenBSC hacker Dieter Spaar

The German podcast  Kuechenradio has released  Episode 297: Hacker im Wald, covering OpenBSC founding member  Dieter Spaar and his activities regarding GSM, UMTS and TETRA security research.