Carpe Noctem #2

After a long, arduous development road, I’ve enabled CyanogenMod nightly builds for the Sony Xperia Z. This brings nightlies directly from CM11 to CM12.1, which hopefully all users will enjoy. Thanks to everyone at my XDA thread, especially Andy van der Steen, who lent me his phone for development. Without that, I would never have come this far.

Xperience F2FS

Starting with early March 2015, CyanogenMod for the whole original line of Sony’s Xperia Z devices support F2FS, a filesystem optimized for flash memory. Tests have shown it to outperform the default ext2/3/4 that we used previously, so definitely a nice thing to have.

However, if you want to benefit from F2FS, you need to manually convert your phone. Be aware that this needs some understanding of how to use ADB and the conversion process will DELETE all you user data/settings!

First, you need to have CyanogenMod 12 or higher installed on your phone, and be using the official recovery. Also, you need ADB installed and ready to use on your computer.

This is how you convert to F2FS:
– Connect your phone via USB and boot into recovery mode
– Open a command line and type “adb shell”
– Type “mkfs.f2fs /dev/block/platform/msm_sdcc.1/by-name/cache”
– Type “mkfs.f2fs /dev/block/platform/msm_sdcc.1/by-name/userdata”
– Reboot the device

CyanogenMod Fusion

In January, I’ve been added as a device maintainer for Sony’s fusion3 platform on CyanogenMod. That platform includes the original Xperia Z line of devices (Z, ZL, ZR, Tablet Z, Tablet Z Wifi). Most of my work went into the platform and the 2 tablets, since I actually own one of these. By now, I greenlighted the tablets for CM12, and they are now official CyanogenMod nightlies. , they are my main target of development. The phones will trail a bit, since I need to rely on others to test fixes and features for me, mainly through a thread on XDA.

Slow TomTom

Cherish your old satnav, despite it being a bit slow? Have map updates you want to transfer over, but it takes 14 hours or more to complete? Here is a hint: stay away from USB3 ports, that should speed up the transfer… Way to go, TomTom (One, XL).

SecurePlatform to Gaia

Checkpoint switched the platform for their security products from SecurePlatform to Gaia. Sooner or later, a switch to Gaia will be necessary… Well, there are plenty of documents about this topic out there. Rejoice, people, one follows right here – valid for small installations (standalone boxes, really).

First of all, you want to get the current configuration from your box. You need to understand that this consists of 2 parts: the OS level configuration (interfaces, routing table) and the CP database (rulebase, CP settings). Checkpoint provides tools for the latter, but not for the latter.

On the OLD firewall
Preperation:
1) Download this script
2) Get the target migration tools from Checkpoint. Either from a box with the target software installed, or from their download center
3) Copy both over to the box, by any method that works for you (TFTP, FTP, USB, magic)
4) Extract the CP upgrade_tools
5) Spread some execute permissions if necessary! “chmod +x splat2gaia.sh” and “chmod +x migrate”

For the OS level configuration
1) Execute “splat2gaia.sh”
2) Copy the output somewhere safe

For the CP database
1) Execute “migrate export”
2) Copy the resulting TGZ file somewhere safe

On the NEW firewall
Preparation
1) Install a fresh Gaia image, if not already installed
2) Follow CP’s guide and finish the first time configuration wizard

Restore the OS level config
1) Get console access to the box
2) Copy the output of splat2gaia.sh over line by line, or copy it into a bash script

Restore the rule database
1) Copy the TGZ over to $FWDIR/bin/upgrade_tools
2) Execute “migrate import”

Almost done! Now, connect to the box via your newly installed SmartDashboard, and install the rule database. Only after that step will the rules be enforced!

Note: depending on how you perform the switch over to the new platform, you might get a ton of “TCP packet out of state” errors. In that case, you might want to go to general options -> stateful inspection, and disable the “drop out of state packets” for the first couple of hours of operation.

Smart phone RIL

After tinkering with cameras and solar power systems, it was time to play around a bit with Android – in the form of CyanogenMod. After setting up a build environment for my i9100 (a Galaxy S2 in marketing terms), I decided to help figure out a problem with open-sourcifying one of the libraries for it, namely libril (part of the radio interface layer).

This device has a history of freaking out OSS people, and libril was no different, as can be seen in the code review for the library. While the same code would work perfectly fine on similar devices with similar radios, it kept crashing on the i9100 upon dialing out. After some debugging, I found out that the UUS (user-to-user signaling) handling was causing the crash – a MEMMAP SIGSEV error!

Namely, it was memset(&uusInfo, 0, sizeof(RIL_UUS_Info)); that caused the kernel to freak. Intermediate solution? Remove the UUS information, as it is not really mandatory. The question remains: why can’t the phone allocate the (little) memory required for this struct? Might have something to do with heap/stack allocation…