PRYSTINE End-user acceptance survey

Are you interested in self-driving car and willing to help out formulating the industry view on the subject, please help us out. One of our partners in the PRYSTINE project is gathering information about people’s opinions on highly autonomous vehicles using an online questionnaire. You can find the questionnaire over here.

Shining a Beacon for Science


The World Community Grid (WCG) has surpassed it’s 14th anniversary and asking to write a nice article about the good work they employ.

The World Community Grid has been a beacon for science to people who understand the need of continuing research since it was created in 2004. What started out as a relatively small, short-term proof of concept initiative has grown into a major source of computing power for 29 (and counting) humanitarian scientific research projects. So far, this has led to breakthrough discoveries for childhood cancerwater filtration, and renewable energy, as well as many smaller discoveries that may one day lead to future breakthroughs.

Working together for a better and more connected world is a noble cause and a great moment to bootstrap the blog postings again.

December is traditionally a month of giving back to good causes and since our servers are running on green renewable energy they have been configured to donate their spare CPU cycles to WCG. With the intention to continue support throughout the year.

You can find our statistics here. If one also has hardware running which could donate a few spare cycles of CPU or GPU power, feel free to check out their website.

Potentieel hoge kosten bij gebruik M2M SIMs met vast IP

We kregen vandjohnny_automatic_bag_of_moneyaag een case over een grote rekening op een M2M SIM met fixed IP te horen (van MCS). De case ging als volgt: Vanwege het feit dat een vast IP over het hele internet te bereiken is, is dit IP dus ook te bereiken door geautomatiseerde ‘bots’ die door de ‘duistere’ mensen van het internet gebruikt worden om te kijken welke systemen kwetsbaar zijn door aan verschillende poorten te gaan ‘kloppen’. In sommige gevallen sturen ze een DDOS (een berg informatie) naar het fixed IP van de M2M SIM. Omdat het verkeer door de mobiele provider afgeleverd wordt bij de SIM kaart zal je voor die verstookte MB’s dus moeten betalen.

Zonder actieve monitoring, filteren en/of limieten kan dit dus aardig in de papieren lopen. Met 6 cent per MB is 10GB verstookte data dus 600 EUR. En 10GB data is op een 10Mbit/s 3G verbinding in ongeveer 2,5 uur verstookt. Dat is dus ongeveer 5000 EUR per dag.

Er is een aantal manieren om dit te voorkomen:

a) gebruik maken van een ‘gewoon’ IP, dan wordt deze namelijk geNAT, waardoor er niet direct informatie naar de SIM gestuurd kan worden. Nadeel is dan wel dat je een (VPN) tunnel op moet bouwen voor remote onderhoud (wat een remote end-point kost) en de verbinding moet blijven onderhouden (wat data kost).

b) afspraken maken met de provider dat het fixed IP enkel maar vanaf een bepaald vooraf gedefineerd IP adres bereikt kan worden (de provider moet dan van te voren gaan filteren wat echter vaak niet mogelijk is).

c) gebruik maken van een private APN om zo je eigen ‘private network’ op te zetten, waarbij anderen geen toegang meer hebben tot jou systemen, en jijzelf alleen via een firewall/proxy het Internet op zou kunnen.

d) enkel de M2M aanzetten in het portal op het moment dat het nodig is en met een strakke limiet om zo (dikke) overshoot te voorkomen, met het risico van vergeten, of van opzettelijk niet, uit te zetten.

e) Contact opnemen met AnyWi zodat zij een passende oplossing voor uw uitdaging kunnen bedenken.

NB: De SigQ-router, welke geen fixed-IP SIM kaarten hebben, hebben hier uiteraard geen last van.

Bad customer care


I managed to screw up my Skype password, so I headed over to the Skype password reset page to get things resolved. No go. The link failed, on any platform I tried. Got locked out, tried again after 24h, but still nog go. Then chatted to customer service (after some digging to find the link to online chats; they don’t want people to find it easily I guess). Still no go. The password didn’t want to reset. I drew a blank.

Now what?

The thing that struck me as particularly cruel was that there was no way Skype was going to help me. The chat resulted in them telling me that there was nothing they could do for me. And I wasn’t able to resolve the problem either apparently.

Leaving anyone just dangle with no options is bad customer care. Lessen learned? Always provide your customer with a next step, be it somewhere to go, a document to read, a forum to go through, propagate the problem internally, anything.

(*) The problem was a glitch on their end: hotmail accounts are valid for password resets, even if they are not associated to a Skype account. The person in the chat should have been able to tell that that was happening. Once I used the correct e-mail address the issue was resolved.

IPFW NAT and FWD combined

For the past year using (kernel) NAT together with FWD rules in ipfw has walked across my brain more often than I like to admit. But everytime I was not able to grab the concept sufficiently to get it right and make them work together. Finally today in the train, trying all sorts of combinations, pondering why it still did not work, I finally got it: If I cannot make the rules on the NAT and FWD match, I should match first, use skipto and then apply NAT and FWD to all traffic that passes in that block of firewall rules!


# NAT and forward both need to process the same packets
ipfw -q disable one_pass
ipfw -q -f flush
ipfw -q nat 123 config if em1
ipfw -q add skipto 1000 all from any to not
ipfw -q add skipto 65534 all from any to any
ipfw -q add 1000 nat 1 all from any to any
ipfw -q add 1100 fwd all from any to any

where is the gateway on em1. Now, this recipe is still missing the inbound NAT, performance considerations due to applying NAT multiple times on the packet, and probably much more, but the basic nut on how to format the ipfw ruleset has been cracked. The roost has left the nest. Policy Based Routing, here we come!

Note: after disabling ‘nat’ rules are no longer terminating the rule set, but ‘fwd’ rules are!

EuroBSDCon 2013

EuroBSDCon mascot

Smiling and helpful as usual, your BSD daemon

And there it was! All geeks unite! BSD lovers from all over Europe and the rest of the world gathered in Malta to discuss what was going on in the world of FreeBSD, NetBSD, and OpenBSD. The talks where better than ever (only 42 out of 75 submissions made it into the 3 tracks on 2 days).

Most impressive for me was the number of people using NanoBSD as a tool to provide their server, embedded systems, and node installations. But also in-depth discussions of fundamental issues like 64-bit time_t, security technologies, and performance enhancement). And of course the fun talks by the BSD veterans McKusick and phk. All in all a good BSDCOn. See you next year!

AnyWi en Wireless Leiden zorgen voor WiFi in Olympisch Dorp

Vrijwilligers van Wireless Leiden hebben samen met AnyWi Technologies ervoor gezorgd dat in het Olympisch Dorp van het European Youth Olympic Festival (EYOF) WiFi-Internet beschikbaar was op de meer dan duizend kamers op de Uithof en de Internationale Campus van de Universiteit Utrecht. Het WiFi-netwerk is in enkele dagen tijd geïnstalleerd. Dit filmpje geeft het proces aardig weer.

Uitdaging was dat het niet alleen operationeel, maar ook te monitoren en veilig moest zijn. Voor de beveiliging is gebruik gemaakt van het eduroam systeem van Surfnet. Medewerkers van AnyWi en vrijwilligers van Wireless Leiden hebben enkele maanden aan de voorbereiding gewerkt, honderden accesspoint-systemen gebouwd en deze in de over 12 verschillende gebouwen verspreide kamers geïnstalleerd. Het festival heeft van 14 – 19 juli plaatsgevonden in Utrecht.

Raspberry Pi running FreeBSD

I received my Raspberry Pi, downloaded a torrent for FreeBSD Pi, and about 10 minutes later spent 1 hour zeroing, then backing up, then dumping the image onto a 8GB SD card. Spent another five minutes figuring out the power requirements (700mA over USB with a running ethernet connection, so an Apple iPhone USB power supply would do), powered it up, connected it to a network. Et voila!

root@fbsd-pi:~ # dmesg
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0 r245446M: Tue Jan 15 12:53:26 SGT 2013
root@fbsd10:/usr/obj/arm.armv6/usr/src/sys/BSD-PI arm
CPU: ARM1176JZ-S rev 7 (ARM11J core)
Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
WB enabled LABT branch prediction enabled
16KB/32B 4-way instruction cache
16KB/32B 4-way write-back-locking-C data cache
real memory  = 536870912 (512 MB)
avail memory = 451756032 (430 MB)

And this all based on open source hardware and software. Next step is to actually modify our NanoBSD environment to build images for this platform.

UPDATE: It looks like getting our stuff running on that platform is actually more work than expected, especially the cross compiling is going to be a challenge. So, back onto the Someday/Maybe pile…

Open Source advantage

Consider this bug report for iTerm2, a terminal program for Mac OS X, where it panic’s Mac OS. The bug has been around for a while. There is no way you can actually check with Apple whether this issue has been resolved, is being worked on, will be resolved when, etc. That bug report by now contains a possible fix based on the Open Source version of the OS. In an open source OS this would be a) fixed by now by someone having the problem, b) probably be included in a release that has already shipped, and c) if not included, patchable in your local system by yourself.

The advantage of closed source is obviously blame allocation: It is their fault because I, the paying customer, say so. However, that is not much help on a thursday evening when struggling to make automated updates of 450 NanoStation M2’s work, with a laptop that crashes every hour.

DNS in a mixed VSat / 3G environment

In this mobile application we use a VSat (Internet over satellite link) for the heavy lifting and 3G as a fallback connection. One of the biggest issues with VSat is its latency of 700msecs up to 5000msecs, depending on the location of the satellite, and other factors. In today’s environment, with heavy dependence on DNS to provide content from different locations (hello, CDN providers!), DNS becomes a bottleneck on VSat systems.

This problem can be reduced at limited cost by doing DNS over 3G (when available). The downside to this is that availability of DNS servers changes heavily depending on the connections available. 3G is not generally available on rivers, so these DNS servers tend to arrive and disappear frequently.

Second, VSat tends to loose signal when turning too quickly, when moored in a deep lock or behind a building, or when crossing under a bridge. To provide Internet access as much as possible we automatically switch the default route to 3G when we loose signal, and switch back to VSat when reacquired. This switching again causes appearance and disappearance of DNS servers, but now also the DNS servers behind the long latency VSat link. Dropping information on timing of these DNS servers needs to be avoided to make sure that DNS servers reachable over 3G are preferred when they both come back.

With the unbound caching DNS server we’ve got a tool that allows us to modify several parameters:

  • add and remove DNS forward entries
  • flush DNS entries, whole zones, but also DNS resolver information
  • provide local subnets / precreated zones
  • increase the minimum TTL of a DNS entry from seconds to minutes to reduce requests
  • do pre-fetching of DNS entries
  • look at DNS resolution statistics of the running daemon

Many of these features will disagree with normal behaviour on the Internet, but given the audience on board, it is generally preferable to speed up name resolution. Adding host specific routing entries for the DNS servers, and using open DNS resolvers (Google and Level3) performance has improved considerably.