Tinkering with Raspberry (and other things)

OSX El Capitan 10.11.4 and the CardDav Bug

I have been moving my OwnCloud instance to another provider and while I was at it, I migrated to nextCloud. Everything worked fine on all my devices. Even the newly acquired Windows Surface Book did not have any problem with syncing my contacts and calendars.

Well, for the Macs running El Capitan, things are different. There is a well known bug with the way El Capitan handles the carddav-protocol and Apple has not been able or willing to fix it. There’s loads of information about this on the internet but with 10.11.4 these workarounds stopped working (at least for me). After spending 2 hours editing .htaccess files and trying every possible permutation of servername and path in the “Internet Accounts” panel on my machine, I finally found a solution.

First, you still need redirects. My NextCloud installer did add them to .htaccess on its own. If you are running NextCloud or Owncloud in a subdirectory of your domain just add a .htaccess file at the webroot directory. The following lines did the trick (assuming the cloud installation is in subdirectory “MYDIR”):

RewriteEngine on
  RewriteRule ^\.well-known/carddav /MYDIR/remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /MYDIR/remote.php/dav/ [R=301,L]

On to the System Settings -> Internet Accounts on the Mac.
Add an new CalDav-Account in the following manner:
Account Type: Advanced
Password: userpassword
Server Address:
Server Path: /MYDIR/remote.php/carddav/principals/USERNAME/
Port: 443
Use SSL: X

With these settings I was able to start the Contacts app and after a few seconds all my contacts appeared. If you open this account via the Contacts app’s Settings menu you will not see the Server Path you added in the above steps. Do not try to edit this path.

Mac OS – El Capitan bluetooth discoverabilty

I recently upgraded my Mid 2011 Mac Mini to El Capitan and had to discover that when Bluetooth was switched on, the machine stayed discoverable via Bluetooth. Living in the middle of a big city this is a gerat security risk. I just don’t want everybody in the neighborhood to be able to see my Mac.

There are numerous instructions on the internet on how to disable the bluetooth visiblity via terminal commands (e.g. at but none of that did work. So I decided on checking the alternatives. And succeeded, thus this blog post. Continue reading

1 Comment

Quick Tip: Which Bluetooth Services Does My Mobile Phone Offer

Ok, this has nothing to do with either the Raspberry Pi or any Android device but I think it may be helpful. At least it is for me.


I own a car with a rather expensive and somewhat “feature rich” hands-free equipment. It is capable of using the normal hands-free profile (HFP) or, and that is my preferred connection method, something called “rSAP” (remote SIM Access Profile). This means that the phone transfers the SIM credentials to the car’s system and this is then acting as a mobile phone with my SIM-card inserted (when, in fact, my SIM card stays in the mobile phone). The advantage of using this profile/technology is that the car uses its own outside antenna thus having less electromagnetic signals inside the car and a much better reception of signals.
As I came to understand the rSAP technology is not much used outside Germany/Europe. In fact, from discussions with friends from the US I came to the conclusion that rSAP is fairly unknown there.

The Problem:

rSAP is not a standard component of Android. There is an app in the Play Store that works (more or less) but it needs a rooted phone (no problem here, that is the first thing I usually do on my mobiles). Some Samsung mobiles (S2 and S3) with some (not all) Samsung stock firmwares do support rSAP.
And here’s the catch: if you update the Android system on the phone there is no guarantee whatsoever that the new version will have rSAP support built in. And most annoyingly, contacting the Samsung support does not help because the people there have no idea what “rSAP” is.
So what you could do is update the phone, walk to your car and check if rSAP works. Which, in may case is not very efficient because my car is parked in an underground car park 5 minutes from where I live. So I need to walk to my car, drive it out of the car park, check if everything works and then drive the car to my underground car park again…

The Solution:

Bluetooth services are announced or better, can be queried by applications. So it is much more convenient to flash a new Android version, query the Bluetooth services available from my computer and then continue or (after some swearing) revert to the previous Android version that had the rSAP service built in.
On my Mac there is an app called “RDP Browser“. It is freeware and works like a charm, even with Mavericks.

So my “workflow” now looks like this:

  1. Make a backup of my mobile phone
  2. Flash the new firmware
  3. Connect the mobile via bluetooth to the Mac
  4. Run RDP browser and look for a service called “SIM Access Server” and “OBEX Phonebook Access Server”
  5. Smile if it is there, swear if it is not and in that case: reflash the old firmware


Here’s a screenshot of the services offered by my Galaxy S3:

Bildschirmfoto 2014-05-23 um 18.39.38

Things were much easier with my Nokia E51. There were no updates and rSAP just worked. Well, in fact I did not yet update to Android 4.3. First of all because I do not want the Knox bootloader, second because I am getting more and more annoyed with Android (and iOS, by the way). It was fun and cool in the beginning but nowadays both operating systems get more and more into “gated communities” and I do not like that. Period. What happened to “Do no evil”, Google?

And, before the question arises: I own a Volkswagen Golf GTI Mark VI with the “Premium Freisprecheinrichtung” (PFSE). Why? Midlife crisis and not enough money for a Porsche, I suppose. No, seriouslyy: I wanted an everyday practical car that, when I’m driving it alone, would put an evil smile on my face every time I kick down the acceleration pedal…