I did not want to blog about it due to my intricate knowledge of Openmoko internals and my own past within the organization. But the news has made it to the various mailing lists now anyway: Andy e.g. is now longer working for Openmoko. He has been the main Openmoko kernel and bootloader developer (and maintainer) ever since I left in November 2007.

This is really sad news. There used to be really great engineers at Openmoko some time ago, but at least a number of good, senior folks are no longer working there at this point in time, or are working on a much smaller scope for Openmoko Inc.

Sure, it is not the right way to discuss the details of every HR matter in a public way. But I would have at least expected Openmoko to use the power they have to publish a statement on what this means _before_ the news get released in an out-of-control way by rumors and hearsay. If you allow this to happen, then you subject yourself to somebody else presenting their [distorted?] view of what he believes as reality first, and you (Openmoko Inc.) get into a defensive position.

They were acting quick. TomTom and Microsoft have settled their patent dispute. Of course, it's business as usual. They have to protect the interest of their shareholders, and a lengthy patent lawsuit is probably creating too much uncertainty for business partners.

I don't particularly mind them settling their [sometimes ridiculously trivial] claims on car navigation systems. But the settlement also includes the long-filename-patent that e.g. has been dismissed by Germany's Federal Patent Court about one year ago on the grounds of being too trivial and ISO9660 RockRidge constituting prior art. So given that the highest patent court in Germany has already issued such a judgement, I would be quite surprised to see a completely different verdict in the US. Either ISO9660 is prior art or not. I doubt there's much to debate on it.

So well, MS will still uphold their implicit threat against anyone who uses Linux + VFAT filesystem in a commercial product. In the end, I hope, this will simply drive people away from using FAT or VFAT altogether. It's not that they are particularly great filesystems anyway... and vendors just want to make it convenient for _windows_ users to use their products by enabling them with VFAT.

I've been offline for an entire week, something that rarely happens to me as long as I can think back. It has been great. I took the time to read Cryptonomicon again, and it was just as great as the first time. I also found sufficient time to continue my (still embarrassingly little) chinese studies, and had even more time to think and reflect about my life.

So all in all it is a holiday like it should be. Don't expect any news from me in the blog or by e-mail before March 26th.

For many years, especially ever since 9/11 in 2001, German governments have been pushing very hard for so-called security legislation, removing civil liberties and enhancing the surveillance capabilities of the various government agencies.

The only sensible response is not coming from _any_ political party in the opposition. Neither the self-proclaimed civil liberties friends of the FDP nor the Green party are cutting it.

This, by the way, extends beyond just security/surveillance related legislation, but also e.g. with regard to the use of voting machines in federal elections. Only recently the constitutional court decided that the legislation as well as the actual devices used in the last election were unconstitutional.

The only people involved in the public debate who show a lot of reason are the judges of the German constitutional court (Bundesverfassungsgericht). Particularly the president of the court, Hans-Juergen Papier is a true hero to me, constantly fighting for the values of our constitution - not irritated by the general mood of the day or any hectic political activism by the government.

What is even more surprising: Mr. Papier is himself from a conservative political background: The Bavarian CSU party.

In recent times, there is an actual fight between Mr. Papier and our ultra-conservative home minister (Schaeuble). Mr. Schaeuble is now going as far as to publicly stating things like 'those who want to be part of legislation should aim for becoming of parliament' or 'i have doubts on how far it is constitutional what the constitutional court is doing'.

This is just unbelievable. How can the government afford to have a minister who openly doubts the legitimacy of the decisions of the highest body of justice in this country? If people really cared about justice and our constitution, it should be immediate grounds to dismiss this minister.

This year's BOSSA incarnation has once again turned out as an excellent event. It was good to meet and talk again with a number of people like Marcel Holtmann or Rasterman.

This year it seems the organizers went out of their way to please every speaker. Since their conference shirts were available in three colors (but not black), they actually prepared a special edition of a black t-shirt for me.

It will be important to see how many other conferences can live up to that standard ;)

Since I'm currently at the BOSSA conference and thus basically on a break in my Brazil holidays, I decided I might as well get some work done and imported the zebra/quagga VTY code into OpenBSC. I used a fork of that code that I used some time ago for a never-announced (but in my public svn) 'cardshell' project.

What this means is that we now have a quite nice shell interface into OpenBSC, where you can interactively explore the data structures with commands like 'show bts 0', 'show e1_line' or 'show timeslot'. Over time, I hope we can easily add also interactive commands for [re]configuration, i.e. reconfigure the BTS on the fly, change administrative state via OML, or set TEI/timeslot configurations or the like.

Importing those bits from zebra/quagga has the advantage the we have things like a history and tab-completion without having to spend much time on it. Also, we can use the same codebase for saving/restoring the current configuration from/to a text file.

To give you an idea, it looks like this:

ideapad.de.gnumonks.org> show bts
BTS 0 is of nanobts900 type, has LAC 1, TSC 7 and 1 TRX
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Site Mgr NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Paging: FIXME pending requests, 100 free slots
  E1 Signalling Link:
    E1 Line 0, Timeslot 1, Type OML
    E1 TEI 0, SAPI 255

ideapad.de.gnumonks.org> show trx
TRX 0 of BTS 0 is on ARFCN 123
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Baseband Transceiver NM State: Oper 'RFU', Admin 0, Avail 'In test'
  E1 Signalling Link:
    E1 Line 0, Timeslot 2, Type RSL
    E1 TEI 0, SAPI 0

ideapad.de.gnumonks.org> show timeslot 0 0 0
Timeslot 0 of TRX 0 in BTS 0, phys cfg CCCH+SDCCH4
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Bound IP: 0.0.0.0 Port 0 FC=0 F8=0

I've arrived in Brazil for 2.5 days of Rio de Janeiro before heading to Recife and Porto de Galinhas for BOSSA 2009.

Rio actually was a much more pleasant experience than anticipated, and as far as I can tell after that short of a visit, I seem to like the city - at least much more than Sao Paulo which I felt was a big disappointment while visiting it last year for a similarly short period of time.

Being in Brazil always fills me with some kind of strange sentimentality. I've spent most of the year 2001 in this country, it was my first long-term experience in a foreign country. It was a great work environment at Conectiva, and times without a lot of the sorrows and worries that I am having today, working with hardware companies who often still not have noticed even remotely what was happening in the Linux world eight to ten years ago.

And I'm always surprised how well I can manage with those few bits of Portuguese that I learned during my 2001 stay. It's actually more than just barely managing, but being able to grasp at least the key aspects of most conversations, etc. And this despite not having had the slightest bit of practice between 2002 and 2007.

If only I could ever get my Mandarin to that level. Well, this is also the reason why I've brought my Chinese language books with me and I'm planning to study quite a bit in them during the two weeks of holidays following after BOSSA. With some luck I can also find some time in May or June to take up my language classes in Taipei again.

As expected, it seems that the various different GSM cellphones expose quite big differences in their behavior towards the GSM network. In part this is due to the evolving GSM standard, where features were added over time in a backward- compatible manner, so old phones still work on modern network. The biggest part is probably due to implementation differences in the GSM stack or the particular hardware drivers that glue the stack to the given digital + analog baseband circuitry in the phone.

I have started to collect a number of different phones to test them with OpenBSC, you can see my current collection here: In addition, at the Berlin CCC we also have an old 8W Siemens P1 for testing against Phase 1 GSM phones.

The old Nokia DCT3 phones seem to be the most tolerant ones when it comes to violations of the protocol. I had a number of bugs, such as using the wrong training sequence in the CHANNEL MODE MODIFY as well as ASSIGNMENT COMMAND messages, but they simply ignored it and used the TSC from the SYSTEM INFORMATION. The various Siemens and Motorola phones are way less tolerant, which is good since it enabled me to actually find the respective bug in OpenBSC.

Also, Phase1 support in OpenBSC hasn't really been there so far. We kept asking the phones for their IMEISV, and apparently Phase1 only have IMEI but no IMEISV, leading to us rejecting the LOCATION UPDATING REQUEST. This is also fixed now. The remaining Phase1 problems are:

• correctly dealing with FR (as opposed to EFR) codec
• figure out why they send a MOBILE IDENTITY TYPE 5 instead of an IMSI on establishing a mobile-originated (MO) call

Finally, it has happened in a public manner: Microsoft sues TomTom over patent violations in the Linux kernel [V]FAT implementation. Sooner or later something like this was bound to happen.

For a number of years, I have heard rumors by various companies producing Large-quantity embedded Linux products that Microsoft is claiming the Linux kernel infringes upon their software patents, and they should sign extensive patent licensing agreements with MS.

The underlying strategy is very obvious: Make those patent licenses high enough to reduce the cost advantage of a Linux based OS over Windows CE and thereby demotivate companies from using Linux in the embedded world.

This has so far happened behind closed doors, but if you google you can find a couple of strange press releases of Asian companies buying into those MS patent deals for Linux.

Now finally, one company, TomTom, has had the guts to stand up against Microsoft and fight their ridiculous claims.

The VFAT patent in question has been invalidated in some jurisdictions, since it has clear prior art: the ISO9660 Rock Ridge Extensions in 1994. Also, in light of the new software patent evaluation rules emanating from the Bilski case in the US, it seems Microsoft has a quite bad stand.

I myself, as well as numerous other people in the Free and Open Source world are asking themselves how this legal action fits into the Microsoft-proclaimed Free Software friendly strategy. As you can see now, that was nothing but vapor.

And MS goes even further. They claim that this lawsuit has no relation whatsoever to Linux, and they're only targeting TomTom's specific implementation of Linux. I have actually reviewed the TomTom kernel sources a number of times during the last couple of years as part of gpl-compliance reviews. I can tell you, there is nothing "TomTom specific" in their FAT FS code. It is the plain fat/msdos/vfat file system like in every kernel.org kernel.

I seriously hope that TomTom will keep up their spirit and be strong enough to fight this attack by Microsoft. We need to see more companies who stand up like TomTom.

Finally, close to 5am after a long day of hacking, I was able to make the first actual voice calls through OpenBSC. This has been _much_ harder than anticipated, with bugs spread all over various places of the code (my code!) as well as some conceptual shortcomings in my understanding of how the exact interaction between GSM 12.21, 08.58 and 04.08 happens.

Initially I was working with the ip.access BTS, but was stuck and didn't see any progress so I decided to try the BS-11, since that one is at least according to spec as A-bis over E1 is publicly documented. Some six hours of problems in my E1 sub-channel multiplexer and TRAU decode/recode later, I actually had a working voice call. To my big surprise, the delay between two phones at the same BTS is incredibly long. Feels like VoIP between two continents.

I then tried whether the fixes have changed anything for the ip.access situation. And yes, they did! It was working straight away, and the delay is non-existent. Isn't it ironic that the traditional E1 system is much worse than the fancy new IP based system? I really need to hunt down where the delay is introduced in the E1 TRAU frame handling, this is not really acceptable right now.

Some further experimentation discovered that my Motorola EZX phones somehow refuse to work, while all the Nokia ones do. Well, some more bugs to fix down the road. At least conceptually everything is working now.

After an intense weekend of hacking, I have made once again quite significant progress with regard to OpenBSC:

• ip.access nanoBTS support is now as good as BS-11 support, i.e. there is no functional difference between what you can do with either of those two BTS types
• As part of this work, A wireshark dissector for ip.access Abis-over-IP as well as some protocol documentation have been created
• simplistic call switching is implemented. This means that you can now register multiple phones to the network, and calls dialled to the extension numbers indicated in the SQL tables will result in paging and ringing of the respective recipient phone. However, voice data is still not routed, even after you pick up the phone.
• internal infrastructure work. OpenBSC now have a TLV parser together with data structures defining the TLV types for every IE in RSL, 04.08 and OML, as well as an internal signalling mechanism where some parts of the code can issue signals while other parts can listen for those signals

This means we're getting very close to being not just an experimental playground but actually doing something useful (like: actual voice calls) soon. SMS switching should also be really easy, in fact much easier than voice call switching. We can already send and receive SMS, but not yet route them through.

Other things on the to do list are: Switch to talloc as memory allocator, cleaning up a lot of the quickly hacked together code, looking for refcount and other resource leaks.

I also want to add an interactive 'Cisco-style' telnet interface for configuration, administration as well as debugging, utilizing the vty code from the quagga codebase

Thanks also once again to zecke for all his help. It's good to not have to care about everything, and just be able to use the working paging layer.

Every reader of this blog will already have read the news about Nokia + Intel merging their Maemo and Moblin projects to form what's now called MeeGo.

I am not quite sure what to think of it. Of course, two big players teaming together to reduce fragmentation of the "true Linux" mobile software stacks (as opposed to Android) is a good move. There can be a lot of synergies from the combined effort of the Nokia and Intel Linux teams...

Maemo always seemed to be heading in the right direction, embracing and growing a developer community. Moblin on the other hand always felt much more like an industry kind of thing. Sure, there were/are lots of well-known developers from the community working on Moblin, but the involvement of the larger Linux/FOSS community seemed to be quite little. So I hope the new MeeGo project doesn't loose the increasingly good community interaction that that Maemo.org was showing.

On the other hand, Maemo was troubled by political decisions such as the move from GTK to Qt (following Nokias acquisition of Trolltech). No matter what you believe is the better technology, changing the UI stack from one version to another inevitably confuses and disappoints all 3rd party application developers.

What puzzled me most about the announcement was this post by well-known kernel hacker Arjan van de Ven, showing an architecture diagram where the Linux kernel is called "MeeGo Kernel". I almost wonder how much they had to pay him to use that diagram in a public article. If they use the Linux kernel, they should simply call it a Linux kernel, even in marketing-oriented architecture diagrams. Everything else is nothing but an attempt at misleading people. Both the Maemo 5 Software architecture and Android Architecture diagrams clearly indicate it is Linux!

Also, the diagram claims to have a Hardware Adaption Software layer below the kernel, which I am quite sure it won't have. No self-respecting Linux Kernel developer believes in hardware abstraction layers.

I've been contacted by a company who will support further development of OpenBSC, including the integration of support for the ip.access nanoBTS. Those beasts are unlike any traditional BTS, as they don't use a E1 link but rather route everything over TCP/IP. They even use Power-over-Ethernet and look almost as innocent as a WiFi access point.

After yesterdays meetings were finished at 7pm, I spent another eight hours of intense hacking and looking at protocol traces between a commercial BSC and the nanoBTS. It seems like everything is as far as possible according to the relevant GSM specs 08.58 and 12.21, which means adapting OpenBSC will not at all be hard, at least not for the signalling part. I haven't yet looked at the actual voice channels, but I'm confident it will all work out just fine :)

It turns out the abstraction of the input interface and introduction of something like a "BTS link driver" during the last weeks has helped a lot to ease the integration of a completely different BTS with a TCP/IP based link.

Unfortunately I currently have to deal with some rather dull and boring other work, but hopefully will be able to continue a lot over the weekend.

Yesterday the members of the deDECTed.org team decided to pronounce me their official spokesman.

It's not that I didn't already have way too much work anyway - but I strongly agree that the project needs somebody who is non-partisan and not affiliated with some of the bigger entities involved with the project.

Hopefully I can use this role to clarify some of the misunderstandings and apparent misrepresentations that the project had to suffer with.

In his recent bog post and mails, well-known Linux kernel developer Pavel Machek is looking for exploitable security holes in his Android phone in order to root it.

He is addressing the very fact that I also cannot re-iterate often enough: If I buy a product, then I own it. If I own it, only I decide what software runs on the device or doesn't run. The cell phone makers and mobile operators make us buy the devices, not rent them. So they have not the least right to restrict their customers from doing whatever they want on the product they own.

If those companies want to own their devices, they should resort to renting phones rather than selling them. But rather than following this logical consequence, they decide to use technical measures to distort the ownership/property situation of the product. They can still charge the customer for the full price of the product and literally sell it, while not actually transferring the inherent power of ownership. It's like selling a car but don't giving the keys along with it.

This is now the "Thanks" that the Linux Kernel developers get from companies like Google, Android or T-Mobile. They thank for being able to use the Linux kernel with locking out the very same people who wrote that kernel in the first place - as well as every other legitimate FOSS developer who wants to exercise his right to run modified versions of the program.

Welcome to the brave new world. I wish I had the time and resources to fight an example case against this kind of behavior. It is not against the wording of the GPLv2, but for me (and my lawyers) definitely against the spirit and the intent of it. Maybe I need to change priorities, as it now isn't only Motorola but also Google/Android/T-Mobile who are engaging in this outrageous act against what is probably the most important practical freedom of Free Software.

For the Motorola MAGX devices, OpenEZX hackers were luckily able to find relatively simple ways to circumvent its security, and thus the practical immediate need for any legal action. Let's hope the G1 has a similar fate soon.

Today I've mostly been in my recently-rented warehouse to prepare the shipment of the next 13 units Siemens BS-11 microBTS

Some people are asking: Why are you doing something like renting a warehouse and taking care of shipping those heavy (48kg each) units?

The answer is simple: I care about IT security, and GSM is (just like DECT or Mifare) one of those massively-deployed systems with much too little security research going on. It has security issues that were known for probably about a decade now, with nobody working on any fix.

In order to encourage more security research (aka 'hacking') of GSM, we need to give the required tools into the hands of more people, and make sure those tools are not too expensive. The BS-11 in combination with OpenBSC will hopefully have this kind of effect: More people playing with the GSM protocols, discovering and releasing protocol as well as implementation weaknesses.

If you ever wanted to see how your mobile phone behaves when you use (in the Internet) well-known attacks such as fuzzing, projects like OpenBSC(+BS11) or OpenBTS finally put you into a position to do so.

A couple of days ago I posted about Reflections on the hardware industry which received quite a bit of attention and feedback. Great!

A number of people raised the issue that the chip-makers cannot deal with lots of small-volume customers. I am very well aware of that, and that was not what I was suggesting at all. But if the chip-makers take action that helps the downstream customers of their tier-1 customers (the board-makers), then in the end everyone is able to address a larger market. No additional support/sales required, no need to deal directly with more and smaller customers.

All I'm arguing for is a deeper understanding of the downstream market, for more care what happens beyond the next element in the supply chain.

I'm currently quite frustrated with a lot of the work that I've been doing recently. As some of you know, I've been talking a lot to various players in the semiconductor and embedded board-level industry, trying to educate them about the Free and Open Source Software development model and the specific business advantages that they might get from opening up with their code, or even actively going mainline, or providing freely available documentation.

You know the names of some of the companies that I've been talking to, but I can assure you there are also a number of companies about whom I didn't blog or whom I don't mention publicly. In this blog article, or any follow-ups, I will refrain from mentioning any names. I do not want to point at specific organizations, but rather just raise the awareness about industry-wide observations that I'm making. They reflect - as everything - my own, personal view and do not represent anyones' opinion.

In the end, there is a surprising similarity to the situation to all of those companies, independent in which country they are, how big their market share is, and in which particular market they deal.

They all have some people inside their own organization, most often actual engineers or even engineering managers up to the very senior R&D managers who understand the FOSS model and the benefits that this would or at least could bring to their products and their organizations. They want to release the source, they want to push mainline, and they might even want to release the user manuals.

But inside the industry, nobody listens to what their own R&D department or event some external entity - even the very representatives of the operating system they use (Linux). The chip makers will only listen to one thing: Demand from their tier-1 customers. Whatever is in the spec of those who buy their components in millions of units will get implemented. Only those maybe biggest five board-makers are considered 'customer'. Everybody else is not. The Telco who buys from the board maker _might_ still be perceived as having some indirect influence, but the actual end customer, both corporate and private, does not exist.

On the other hand there are those many small, innovative start-ups and medium sized organizations at the other end of the market who want entirely open source Linux drivers, in recent kernel versions, because that is what they can use as the basis for innovative products. But they are invisible to the chip maker.

The entire food chain in between, at least one level of OEM and ODM - possibly more - prevents the actual existing demand from those smaller innovative companies to ever reach what the chip maker perceives as specs. Those intermediaries (OEM/ODM) typically have very limited skill and understanding about anything related to Software, not even talking about FOSS. They know how to make many boards cheap. In fact, their skill typically is so low that all they can use for their products are so-called turnkey solutions: A full reference board design and complete software stack that they can copy+paste with only the most superficial modifications.

This is why no single mainboard maker (probably apart from Intel's mainboard division and some parts of Dell) ever tries to boot a Linux Live-CD on one of their boards before shipping it, or bothers to get their ACPI tables correct. Whoever buys most of those boards doesn't have "ACPI compliance" or "Linux support" in their specs. The fact that there are hundreds of small companies who each might do thousands of units for niche markets desperately look for products with good Linux support [which is impossible without open source] doesn't matter.

Or in the embedded networking market for DSL modems, WiFi routers or the like, none of the large buyers (i.e. ISPs or Telcos) has "frequent security updates" on their spec. The security updates would be something that requires the chip maker to use (and follow) more recent kernels, and could even drive them away from proprietary kernel modules, since the ABI and API incompatibilities would probably make them quite hard.

So despite senior R&D management at the chip makers understanding those dynamics, and knowing that they could achieve superior product quality, reliability, security and encourage innovation - the companies don't do it until the requirements show up on the major buyers shopping lists.

The fact that the current policy of not releasing documentation and providing source code only to their immediate customers, as well as the frequent abomination of binary-only kernel modules also effectively prevent any independent third party (commercial or non-commercial) to actually provide such a solution based on a particular hardware offering.

Thus, it is actually not an anti-FOSS environment, but an anti-competitive environment. By opening up at whatever level and enabling (or even encouraging) any third party to build on top of your product, you encourage a market and encourage competition. A market with actual competition will increase innovation due to competition. In the end, any customer who wants to use the actual chip will have more software options, and thus the resulting product will be able to reach more markets and boldly go where it hasn't gone before.

As a chip maker, you first and foremost concern should be to sell as many units as possible. You don't care what kind of software your customers use. You don't care where they get their software from, or what development methodology they use. So if you can take any step to encourage more alternatives and more competition/innovation on top of your chip, you can only gain market share, but not lose it. And if you don't gain market share, well, you didn't have to make any investment. So no matter what you do, you can hardly loose anything.

I think the key issue is to be able to think beyond your immediate board-level customer. By going open source, you help those board makers (even if they don't know how and why) to sell to markets that they cannot address. And you will see new applications on your chip as opposed to the more closed competition. And in the end, if your customers customers customer sells more, you also sell more.

So as a chip maker, you can either sit back and wait for your competition to fully realize this potential, or you can proactively take steps ahead and be the first one. First time-to-market is key. Why can everyone afford to sit back and do nothing, despite the increased pressure from a collapsing market/economy?

After last years' experience at BOSSA 2008, I was very interested to attend BOSSA 2009 in Porto de Galinhas, Pernambuco, Brazil. This time I hope I can contribute by talking about the various FOSS projects in the GSM protocol area, such as gssm/gsm-tvoid, OpenBSC and OpenBTS. Lets hope I can get some more people excited about liberating the protocol part of mobile communications devices.

Like last year, I will also add some holiday after the conference. The nice and empty beaches of Pernambuco and Alagoas are quite irresistible during the off-season.

Tomorrow at 2pm CET, I'll have a live interview in the Breitband show at the nation wide Deutschlandradio station. The show covers the topic "Open Source and Business", and they want to talk to me for a couple of minutes about the side-effects of businesses getting involved with copyleft-style FOSS without respecting the rules as put forward by the licenses.

In late 2008, I 'sold' my old car (Opel Vectra) to a friend from the local Berlin CCC (starbug) for the symbolic price of 1 EUR. I didn't mind, since the car was not worth all that much, and it was for a friend.

As it turns out, starbug immediately said "if you need it back at any given time, just let me know". I never thought that case would happen, but due to recent events it actually happened.

So now I have my old car back, which makes the feeling of the Golf even more surreal. Owned a car for about 3 months of which I was probably travelling at least two, then suddenly lost it, and am back with the old car. Feels a bit like I'm back in the past, rewinding back to times that one thought were gone.

In any case, big thanks starbug!

It's been a very long time since I've actually been touching any application code using serial RS-232 ports on Linux or similar OS's. If I think more about it, it's probably about a decade now.

So in the last couple of days I was starting a program called bs11-config, a small command line tool for initial configuration of the BS-11 GSM BTS, part of the OpenBSC project.

The longest part of that program was actually not the code for the program itself, but rather finding out how to properly configure the serial port in a way that it really is completely raw, i.e. doesn't meddle with any of the rx or tx bytes in any possible way. It's always amazing how baroque some of the traditional UN*X interfaces are - particularly something like serial ports which traditionally have only been used to transport ASCII characters to serial (hardware) terminals, modems or similar equipment.

In any case, it's now working just fine. No more need for any proprietary 16bit windows programs such as LMT (local maintenance terminal) for doing the initial configuration of a BS-11. What a relief.

What I found incredibly useful was the Serial Programming Guide for POSIX Operating Systems. Thanks, Mike!

Today I arrived in Berlin and could take some pictures of what was my car:

As you can also see on the following pic, I was "lucky" not to be the owner of the Porsche next to it - apparently the actual victim of the attack:

What I cannot describe or show here is the actual smell of that burnt car.

Rest in Peace.

UPDATE: There's even a picture while it is still burning in the newspaper

While I'm still in Taipei, I suddenly get a mobile phone call from the Berlin police department. It seems that somebody has parked a Porsche next to my car, and then some retarded people put that Porsche on fire, and the flames from the Porsche then torched my car (a VW Golf), too.

I currently don't know the extent of the damage, but it makes me quite sad, as I just had that car for some three months. Luckily I'm leaving Taipei today, just in time to get home tomorrow and have a look at my [partially?] burnt car.

Oh, and it still had one of the BS-11 GSM Base Transceiver Stations in the trunk. Curious to see if and how that one has survived.

So I'm returning to my home in Berlin. The car is torched. My BMW F650ST motorbike is broken due to some carburetor issue. And the Yamaha FZ6 is only registered from March through October for the summer season. *sigh*. Must be Murphy's law.

As if I didn't have other things to do.

UPDATE: The car is apparently completely burnt out, beyond repair.
Farewell :(

I've taken the DX900 apart and taken the usual PCB photographs. You can find them attached to the DX900 page in the gnufiish wiki.

In the process, I learned some new bits about the DX900:

• They have used a Sunplus 2.5G modem (next to their usual 3.5G modem design)
• They have added a second small CPLD (2C64)
• They are now using a Power Management IC (older glofiish don't)
• The DX900 does no longer have the standard glofiish test pad arrangement like all earlier devices
• There probably is no M900 (key-board version), since the PCB is now heavily using components and shielding covers on both sides, adding to the overall thickness of the device