Belkin still not in full GPL compliance

Belkin seems to be one of the hardest cases we've had so far. It always seems like they're now in compliance, but then something else happens or a new fact appears, and the whole story starts all over again.

Their firmware is compiled with a modified version of gcc-3.2.3 ("Broadcom modifications"). Thus, they need to ship that modified version of the gcc, which is what Belkin now does. However, gcc itself is again GPL licensed, and they need to provide the full corresponding source code of gcc, including any 'Broadcom modifications', too.

It's not really our job to look for every piece of code they release and check it thoroughly for license compliance. It's their job.

Btw, Linksys seems to have similar issues, too.

When will they ever get it?

Adaptec violating the GPL

Adaptec is shipping a number of products in an GPL in-compliant way. We've already enforced the first infringing product that I learned about, the Adaptec iSA1500, an iSCSI storage array.

Instead of showing the community their support and at least providing the full corresponding source code on their download page, they now require you to send a written letter to their legal department to a US postal address in order to get the source code for a specific product.

This really looks like they're trying to make it as hard as possible for anyone to get the sources, while still staying withing the boundaries of the GPL.

I don't really know what they gain by that.

Back to Curitiba after 4.5 years

So this was my first day of Curitiba, after being on a scheduled-11hrs but finally 13hrs bus ride from Porto Alegre through the interior of Rio Grande do Sul and Santa Catarina. The bus ride was really nice, something that I could be doing every day ;) Lots of interesting landscape passing by, very comfortable seats and an extremely quiet atmosphere. I had lots of time to listen to music, do a bit of hacking (though typing is a bit difficult considering the condition of many roads), reading as well as thinking about various aspects of life, the universe and everything ;)

I've also encountered to signs that are note mentioning: One was translated to "smile! you are being filmed by surveillance cameras". The other one was "This hard shoulder is provided by the federal government". ;) Unfortunately in both cases I didn't have the time to get my camera out and ready to take a picture. SLR's are just not the right tools for quick snapshots.

In Curitiba itself, it was nice to recognize the various places once again. I yet have to go to my former apartment, but I've seen the former office of Conectiva, the commercial center, etc. Everything has changed quite a bit...

First I was thinking of hiring a motorbike here for a bit of travelling - but then I recalled that riding a bike while having a bit of a flu is not really a good idea, so I'm actually hiring a car for two days now. Planning to visit Vila Velha and Santa Felicidade (which apparently claims to have a beautiful cemetery, for Brazilian standards).

At night went out for dinner with Claudio Matsuoka and Helio Castro. Talked a lot about my travels to India and got them interested in travelling there at some point.

Tomorrow I'll probably be mainly working. Having broadband at the hotel always has a good and a bad side. There's always a pile of work waiting...

Trying to get the Omnikey CardMan 4040 to work with OpenCT

Following up my recent patch implementing support for CardMan 5121 and 4000, I'm now currently working on adding support for the latest PCMCIA version, the CardMan 4040 to OpenCT.

The CM4040 seems to be a CCID USB reader with some glue to attach it to the PCMCIA interface. So instead of receiving URB's via the USB stack, you pull them out of a FIFO in the card's I/O address space.

So the first issue is that the CCID code in OpenCT (as much as everywhere else, AFAICT is USB dependent. I've now tried to separate the CCID code from the USB dependent part, and I must be very close to the final solution, since I already see the ICC POWER ON request being sent to the card, and the reply coming back from the card. Now OpenCT calls poll() which is not supported by the kernel, we get -EXIO and disregard the reply from the kernel.

So with some luck, I'll have it running at some later point today.

Arrived in Zagreb for CLUC

12 hours after leaving my apartment in Berlin yesterday I finally arrived in Zagreb, Croatia. No, I didn't go by car, but I was using planes.

First I took a MALEV Berlin -> Budapest flight, only to learn in Budapest that the connection to Zagreb has been cancelled. After a four hour delay, they got me onto a Flight back to Germany (this time Frankfurt), where after two more hours I was scheduled to connect to Zagreb.

When arriving in Zagreb, my Luggage didn't appear, so I went to the lost luggage office. To my surprise, the luggage had arrived before I did. This despite the fact that the Malev representative in Budapest re-routed the luggage to assure it would always accompany me on my trip.

Anyway, I finals arrived at about 8pm and went for some dinner and beers with Vlatko, one of the organizers of the CLUC conference.

Today I gave a four hour workshop on netfilter/iptables firewall administration. To the best of my knowledge that went quite well.

Tomorrow I'll be giving a regular netfilter/iptables presentation, something that I didn't do for quite some time. Feels good to talk about technical stuff again, after all the presentations on legal issues and gpl enforcement.

Fortinet woes continue

Fortinet has sent out some information to their partners on the preliminary injunction.

They make the following wrong statements:

• The GPL open software project. There is no "open software" and no "GPL open software" project. It's the gpl-violations.org project, and it's about "free software"
• GPL is targeting pro-actively many leading firms. The gpl-violations.org project is not targeting anyone. It just wants to bring commercial users of free software into compliance with copyright and the license terms.
• a very small piece of FortiOS contains GPL software. That is ridiculous. The FortiOS is based on a full Linux kernel, therefore the most important and largest piece of FortiOS is the GPL-licensed Linux kernel.
• We recently [...] have [...] been diligently working with him to resolve this matter [...] and [were] surprised that Mr. Welte pursued a preliminary injunction. Fortinet has not signed a declaration to cease and desist even until today. They were very well informed and warned multiple times that we would seek injunctive relief if they didn't sign such a declaration within a four-week deadline.

As you can see, they're trying to hide the extent of GPL licensed code they use, and they make wrong statements about the gpl-violations.org projects and it's actions.

OpenCT support for Omnikey CardMan 4000 and 5121

As indicated in one of my previous blog entries, I've managed to replace the obnoxious Omnikey binary-only i386 driver for CardMan 4000 (PCMCIA) with OpenCT and some glue code.

I've now managed to get the CardMan 5121 running with OpenCT, too - at least the contact based reader (it's a dual interface reader for RFID and contact based ICCs). This was even easier, there was only one minor bug in the OpenCT CCID implementation that prevented this.

The patch has been set to the OpenSC-devel mailing-list.

Whenever my time permits, I'll be hacking RFID support for the 5121, and a driver for the 4040 PCMCIA reader. With some luck, we'll soon see real Linux (i.e. free software) support for all their devices.

ctnetlink now with flow-based accounting support

Some months ago, I included per-connection packet and byte counters to ip_conntrack (CONFIG_NF_CT_ACCT) into Linux-2.6 mainline. However, reading the entries from /proc/net/ip_conntrack is not really a useful interface to access those counters.

I've now merged Pablo Neira's latest ctnetlink/nfnetlink changes with mine, and patch-o-matic-ng now includes support for dumping the counters to userspace.

With any userspace program (using libctnetlink) you can then retrieve the counters. Either you wait until a connection dies (and receive the DELETE message from the netlink socket, containing the counters), or you regularly issue a request to list-conntracks-and-reset-counters-to-zero request.

The conntrack tool in subversion now already includes support for this, see the conntrack -E conntrack and conntrack -L conntrack -z commands.

I've also picked up working on ulogd2 again, to provide a all-in-one solution that allows you to create IPFIX (aka NETFLOW) records or put the per-flow accounting data directly into a SQL database. If everything works fine, I'll be finished in a week or so.

The largest original collection of Bollywood actresses rendered in ASCII

It's amazing what kind of websites people are starting. This one is definitely one of the most geeky subjects I've seen so far.

Just received my TVRX fronted for the USRP

TVRX is the first real HF frontend by Ettus Research for the USRP. It is based on a microtune tuner and covers 50 to 850 MHz RF.

I'm still intending to build a couple of frontends on my own. One of the most important ones would be a 15.6MHz frontend for ISO 14443 and 15693. Also, I have already obtained a number of tuner samples with I/Q output, which would make perfect match to the USRP.

Meanwhile, I'm still experiencing a lot of problem with gnuradio. While the USRP communication seems to work fine, gnuradio segfaults all over the place. Maybe this is related to x86_64, but I cannot say more about it at the moment.

Managed to obtain a preliminary injunction against Fortinet

Yesterday, the Munich district court granted a preliminary injunction against Fortinet's GPL in-compliant use of Free Software.

Fortinet is shipping a series of Firewall products (FortiGate and FortiWiFi) running on Linux without complying to the GPL.

Legal action was made possible via the "initrd" code, on which Werner Almesberger signed me his rights a couple of months ago.

To the best of my knowledge, Fortinet is not using any of the iptables/ip_conntrack/... code, but something different. We'll see how that is integrated into the kernel network stack as soon as they release the full corresponding source code in accordance with the GPL.

I'd like to thank my lawyer Dr. Till Jaeger from JBB Rechtsanwälte and Jürgen Lüters from Intranet Engineering, the technical expert in this case.

Obtaining (better: Applying) for a preliminary injunction is a tremendous amount of work, so this really is the last possible option if all other options have failed.

Also, making this issue public with a press release was a very well-thought action. Fortinet did not even sign a declaration to cease and desist within four weeks after receiving the warning notice. They apparently didn't want to believe that this is a serious issue. Maybe the public pressure will help getting them back to negotiations.

porting conntrack/nat helpers to post-2.6.11

Unfortunately most of the conntrack/nat helpers in patch-o-matic were broken ever since 2.6.11 was released. The reason is the new semantics of the redesigned conntrack/nat helper API by Rusty Russell and Pablo Neira.

It's not an easy and straight-forward port, and as usual there were not many people volunteering for that job. Max Kellermann is a positive example, he ported the h323 helpers.

I've now ported the all remaining ones BUT the PPTP helper. At the moment I'm not sure whether the PPTP/GRE helper can be ported/used at all with the new infrastructure :( This will need some serious amount of thinking.

All the ported helpers are available from pom-ng. I don't have the possibility to test them, since I don't actually use most of those protocols. Testing / debugging / bug reporting is therefore very welcome. Anyone writing a test case for nfsim would be my personal hero.

More dual Opteron netfilter/iptables benchmarks

The last two days I was at a network performance lab in Stralsund, Germany. We were testing dual Opteron 250 (2,4GHz) machines with e1000 cards and Linux.

One of the interesting results was that ip_conntrack [again] scales better as the load generators. The generators couldn't establish more than 25,000 new TCP connections per second and no more than 1 million total concurrent connections ;)

Thus I'm now pretty much convinced that ip_conntrack scales quite reasonable, and we should concentrate optimizations to other areas of netfilter/iptables.

Windows USERS have less security holes than Linux USERS

I don't usually join the never-ending discussion on proprietary vs. free software, since I know what I think is best for me anyway.

But there is one quote that I'd like to add to this blog, because it's [unwillingly] funny:

That is the literal translation of one of the headlines on the German Microsoft homepage ("Windows-Benutzer haben weniger Sicherheits-Schwachstellen als Linux-Benutzer").