Today I finally received PDF's of the Siemens BS-11 GSM BTS. This means that I'll now be able to actually connect the device to power, E1 and RS232.
Unfortunately I'm still lacking the configuration software for the device, and a corresponding E1 card for the Abis interface. Anyway, seems like we're slowly getting there. Maybe during Q1/Q2 2006 I can spend some time actually implementing code for that beast.
This means that there is now very little code duplication between the mysql and pgsql drivers, since all the high-level functionality is now 'abstracted away'.
I'm not going to write any more about FOSS.in, since everyone else has already written about anything that there is to say. If you want to read all of it, go to planet.foss.in.
One fact that hasn't very much publicized [yet?] though, is the financial trouble that the event formerly known as Linux Bangalore is going through this year. This apparently is almost exclusively to blame at the sponsors (or lack thereof).
Apparently in India it's quite normal that even if you start talking with Sponsors more than half a year in advance, they will not commit until a few days before the event starts. This is also the reason why the conference programme is announced before the sponsors show up on the website (if you checked it before the event, all the sponsor banners were empty).
Due to this strange culture, it could happen that a large Indian IT company dropped their sponsoring commitment almost immediately before the event - that is _after_ the organizers having committed to all the expenses. I don't think that given those conditions, any organizer could have managed without a big large gaping hole in the budget :(
In addition to that, it is is a pity that none of the internationally recognized (and also locally quite present) "open source" companies Novell/SuSE and RedHat didn't show up on the sponsors list at all.
Sometimes I really feel like I don't understand what's going on with some projects and/or developers. The last time I looked at libusb source code, it was the 1.0.7 release - and everything was working as expected. When you submit a bulk/interrupt read request, then it would do a blocking read until the user-specified timeout has expired.
When recently strace()ing a program using libusb, I found out that with my currently-installed version (1.0.10a), it actually does a non-blocking read (REAPNDELAY), then uses select to implement a 1ms sleep, and starts all over again until the user-specified timeout has expired.
This is really bad. Not only clutters it your strace output with lots of noise, but it actually uses CPU, wastes cache lines, and probably most importantly: eats battery on notebooks!
I'll ask the libusb folks what kind of madness this is. Probably it's time to publicize libausb at some point (the libusb-wrapper that I implemented for async URB handling in the ctapi-cyberjack drivers) - and which now uses a copy of the libusb-1.0.7 functions for blocking bulk read/write, too.
I've just checked in a userspace-only version of the cyberjack e-com (0x100) driver. This means that we'll finally be able to work around the many broken old (drivers/usb/serial/cyberjack.c) cyberjack drivers that almost all the distributions ship. Apparently almost none of them seem to bother merging upstream fixes into their trees.
One minor problem though is that both cyberjacks need asynchronous delivery of interrupt URB's, a feature that is not available by libusb. The libausb wrapper library that I developed for this purpose is specific to Linux usbdevio, so the userspace driver won't be working on other libusb supported platforms such as *BSD :(
This is in response to Oh my, this was from running yum update on a 2.6.13 FC3 system and had reached the transaction test but got OOM killed.:
I've seen this numerous times on FC3 (probably even older FC) systems, and no matter how large you make swap, it never really works. The only workaround I found is to manually split the update into tiny chunks, and then update those tiny chunks each itself rather than a full system-wide update.
This is the third day of FOSS.in 2005, for me it's the second day, since I arrived one day late.
I'm having a good time, and the conference has come quite some way since last years Linux Bangalore. To highlight some of the changes:
Also, since the same amount of attendees are distributed over a wide area and more lecture halls, it is less crammed/crowded than the previous year. At least for people from a western country it therefore is way more relaxing, since there is more space between you and the people immediately surrounding you ;)
As the frequent reader of this blog will know: In order to keep track about all the alleged/confirmed gpl violations, and the progress in their resolval, we're now using RT (request tracker).
Since the request tracker was introduced about one month ago, we've received an incredible amount of reports. Today I opened ticket number 64 (!).
I don't really have those kind of automatic statistics on the number of reported violations before, but it was certainly less than that number...
ulogd has practically always been a sub-project of the netfilter project, but was hosted at svn.gnumonks.org for historical reasons. I've now cleaned this up.
ulogd-1.x is now hosted at https://svn.netfilter.org/netfilter/trunk/ulog/ulogd/, ulogd-2.x at https://svn.netfilter.org/netfilter/branches/ulog/ulogd2/.
I've just done a quick browse through the FOSS.in schedule. I'm honored to give my two presentations in the "Stallmann Hall".
There's also an OpenSolaris track. I'm probably going to join that, since I know close to nothing about it (yet).
Sometimes I really think that I'm insane. In the last week alone, I've spent some 7000 EUR in test purchases to prove GPL violations. Yes, I'll get reimbursed once those cases are over, but somehow I feel like giving loans to those companies who don't obey the license. If I'd put that money into a bank, I'd at least get some (crappy) interest rate.
There are so many cases that I would like to write/talk about, but cannot because they're still not over yet. *sigh*. Let's hope I can publish some news before I leave for my 11 day trip to Bangalore for FOSS.in.
When I'm back, I can be sure that there's a stockpile of devices to analyze. Wish I could spend that time with something more productive, though.
Finally, my ported/cleaned up Omnikey CardMan 4000 and 4040 (both PCMCIA smart card readers) kernel drivers have been included in 2.6.15-rc2 pre-release.
Ok, now I am in contact with one guy that managed to run a working kernel that he compiled himself from the source code that Motorola Hong Kong has published.
This finally confirms that the kernel (even though it was requested for E68) works on a A780 without further modifications. On the other hand, I'm a bit puzzled why it won't work here. To figure out where the problem is, I've asked him to pass me the exact source tar-ball that he was using, plus detailed information on his cross toolchain.
I've also started over again from a 'vanilla' Motorola kernel tree and will give it another try. If this works, I'll re-try with the serial console, and if that works, move on to the 2.6.x tree (which I'm planning to make public this weekend, btw).
Meanwhile, I have confirmed that the bootloader is actually based on blob, and thus also needs to be released under the GPL. This, in turn, should facilitate the development of a GPL licensed host-side replacement of PST for flashing the phones.
I'm a bit worried since I'm busy with many other things over the next couple of weeks. But even while travelling, I'll have the full toolchain, sources, and everything with me.
Starting today, I'm the 'proud' owner of a Siemens BS-11 GSM BTS.
If anyone has documentation on
The whole purpose of this exercise is to do some [security] research in the GSM area, and to see whether it can be done to implement the BSC-side of Abis (and a minimum emulation of HLR, MSC, ..) in order to get a phone to talk to the BTS.
This is yet another of my many toy/pet projects, so please don't expect any even remotely useful code anytime soon. Chances are likely that this project won't go anyway due to lack of time.
It seems like DaveM was away, there was some communication problem that lead to the fact that none of the netfilter related fixes went into 2.6.14.y series (up to 2.6.14.2) so far. I'm sorry for that, and all the fixes have been submitted now.
So lets hope 2.6.14.3 will have no known netfilter related bugs.
Today I've finalized my preparations (paperwork, etc) for passing four more gpl violation cases off to my lawyer. As usual, I don't state the names of the vendors/products at this time.
There has been quite some amount of backlog piling up, as I've been busy with other (more interesting, to be honest) stuff in the netfilter, openmrtd and OpenEZX world. Luckily we're now using RequestTracker and hopefully don't loose any reports of violating products.
To be more efficient in flooding DaveM with netfilter patches, I've now hacked up a set of 'wrapper scripts' around my git tree. They enable me to efficiently apply patches to my tree, generate sequential sets, and send them off (actually not using a mail user agent).
This means, that for now my patch submissions are (like those of 99.9% of the other kernel hackers) not PGP/GPG signed. If I find some time, I'll add that feature to my script.
Anyway, I've sent off the first set of 10 netfilter patches and it worked like a charm.
Some of you might have already read it, Sony distributes a 'root kit' with their DRM-encumbered 'copy protected' Cd's. This basically allows Sony to control your computer, once you've installed the software contained on on of their audio Cd's.
While this in itself is already a security nightmare (especially since they don't inform and/or warn the user about this), it gets even worse: According to a number of sources, this software even contains a statically linked version of the LGPL licensed liblame homepage.
I guess this gives a really strong measure: In order to protect our valuable copyright on proprietary music, we don't give anything about the copyright of others, such as authors of free software.
Ok, finally. After David Miller has returned from his holidays, nf_conntrack has 'magically' ended up in the mainline tree. Stateful IPv6 packet filtering in vanilla 2.6.15 is therefore reality.
Thanks to Yasuyuki, DaveM, Acme and everybody else who has made this happen.
Today I had the honour of holding a guest lecture at the Institute of European Media Studies of the University of Applied Sciences in Potsdam. The lecture was entitled "Privacy, Data Protection and Surveillance - Risks and side effects of modern communication technology".
To my big surprise, the lecture was very well received, and members of the institute have suggested that they are interested in some follow-up lectures on other topics such as copyright / software patent / GPL issues.
I've managed to add support for 212, 424 and 848 kBps 14443A support. 214 and 424 seem to be running quite stable, 848 is not very stable. I'm not sure whether there's something wrong with my configuration, or whether this combination of reader and smartcard just are instable at 848k.
Fixed some data corruption bugs in libmrtd as well, and made both librfid and libmrtd use autoconf. There's still lots of cleanup work to be done, but basically one could now start to write a GUI application on top.
While working on librfid support for the Pegoda Reader (which is basically 50% done now), I've discovered what my problem with librfid's MiFARE classic support was: I was using the wrong keys. Apparently Transponders issued by Philips have { 0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5 } as their default key, whereas Transponders from Infineon have { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }.
I seem to have Infineon samples, and I always tried with the Philips key. After fixing this, reading sectors off a MiFARE classic card seems to be working.
Today, I spent a lot of time doing releases of libnfnetlink, libnetfilter_log, libnetfilter_queue, libnetfilter_conntrack and the conntrack program.
The amount of manual XML editing, copying of files, checking in stuff, ... required to do a release is way too much. We definitely need some release automatization.
ulogd2 has now reached beta stage, and it now has almost all the plugins of ulogd-1.x. Only the SQL database backends are missing. It also features a ctnetlink input plugin for flow-based accounting with 2.6.14 kernels.
Next, I'll be working on documentation, testing and on some simple IPFIX output plugin.
In order to make librfid cover more readers than it currently does, I've obtained a Philips Pegoda (aka MF EV700) reader.
It's based on the CL RC500, one of the predecessors of the CL RC632 (which librfid supports natively). However, the low level protocol processing is implemented on a Infineon C161U (C166 core with USB interface), so the interface towards the reader will be on a very different level than for the Omnikey one.