Tuesday, September 13, 2016

Living without Google Play

Amid the news about Google Play turning on location tracking without consent, let me share how to avoid it.
Step one - install CyanogenMod on your phone.
Step two - do not install Google Play.

Now you have a clean foundation to build on, but how to install apps without Google Play? That's actually quite easy - most opensource apps can be had at the F-Droid store.
To install proprietary apps, I use Raccoon on my desktop to download the apk files from Google Play. Once I move them to the phone they can be installed by tapping on them in the file manager.


Thursday, September 8, 2016

Sony headphones useful again

The headphones from my old Xperia Ray turned out to be incompatible with my new Xperia M. They are still fine, but I can't use them with the new phone.
Also they can't be used with a simple MP3 player as the TRRS jack passes the audio output through the microphone, so it's barely audible.
There's the 'press mute button' workaround, but it's quite user unfriendly to keep holding it while cycling...

So, to fix them permanently, I opened the microphone enclosure (a fingernail works well).


You'll notice the two wires marked G and R that connect the mute button.
When shorted, the effect is the same as if the mute button was pressed permanently. And that's what I've done.
A blip of the solder gun and the headphones can be used!


Friday, July 15, 2016

Flipping a GPIO bit on OrangePi PC

Here's the header pinout: http://www.cnx-software.com/2015/09/26/status-of-orange-pi-boards-gpio-support/

Here's the steps: https://linux-sunxi.org/GPIO

So, to up pin 12, a.k.a. PD14 I do:

echo 110 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio110/direction
echo "1" > /sys/class/gpio/gpio110/value

Monday, June 27, 2016

Prince of Persia: The Sands of Time - startup error

I got my free copy of Prince of Persia: The Sands of Time. It installed just fine, but upon startup it'd show a window with "The local sound file is missing please see Readme.txt file for technical support." and quit.

Googling didn't help, so I started looking around.
I found it interesting that there were soundlocal.big and soundlocal.fat files under the Support\inst\data\EN game subdirectory, but there was only soundlocal.fat under the Sound subdirectory. And indeed copying the missing file to Sound fixed the issue.
I'm not sure what happened, but there wasn't much space available wile I was installing it. Perhaps the installer didn't do a proper job of assuring there was enough space and this file got lost as a result.

So far this was the only issue, the game ran smoothly from then on, but after five minutes I found out I don't like the game at all and wiped it :-)

Monday, February 22, 2016

[SOLVED] gqrx crash on startup

I plugged the SDR dongle in and launched gqrx. All seemed to go well, however as soon as I git the 'Start DSP' button, it crashed with
gqrx: symbol lookup error: /usr/lib/x86_64-linux-gnu/librtlsdr.so.0: undefined symbol: libusb_handle_events_timeout_completed

Googling for the error message found just a few hits: An ages old bug caused by bad versioning and a newer question without answer.
If the web doesn't have the answer, I'll need to find it myself, so ...
hajma@debian:~$ ldd -d /usr/lib/x86_64-linux-gnu/librtlsdr.so.0
 linux-vdso.so.1 (0x00007ffc29380000)
 libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x00007f9ea0fd7000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ea0c2c000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9ea0a24000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9ea0807000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f9ea13f3000)

hajma@debian:~$ readelf -s /usr/local/lib/libusb-1.0.so.0|grep libusb_handle_events_
    60: 0000000000005e70   215 FUNC    GLOBAL DEFAULT   12 libusb_handle_events_time
    80: 00000000000058a0    92 FUNC    GLOBAL DEFAULT   12 libusb_handle_events_lock
   237: 0000000000005e70   215 FUNC    GLOBAL DEFAULT   12 libusb_handle_events_time
   258: 00000000000058a0    92 FUNC    GLOBAL DEFAULT   12 libusb_handle_events_lock
Indeed, there's no libusb_handle_events_timeout_completed in there.
hajma@debian:~$ grep libusb_handle_events_timeout_completed /usr/include/libusb-1.0/libusb.h 
int LIBUSB_CALL libusb_handle_events_timeout_completed(libusb_context *ctx,
but the header file has it, what's up? It took me a minute or two to realize that the library resides in /usr/local/lib. That's an unusual place for a Debian library, isn't it?
hajma@debian:~$ ls -l /usr/local/lib/libusb-1.0.so.0
lrwxrwxrwx 1 root root 17 Jan 25  2014 /usr/local/lib/libusb-1.0.so.0 -> libmchpusb-1.0.so
and googling for libmchpusb-1.0.so found me the answer:

This is actually a library supplied with Microchip's MPLAB-X software I installed two years ago. It seems to be an ongoing source of frustration for their users :-)
/usr/local/lib is included by default on Debian:
hajma@debian:~$ cat /etc/ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib
For the time being I workarounded this with simply removing /usr/local/lib/libusb-1.0.so.0 and it works quite well:

Saturday, February 6, 2016

A new screen for Xperia Ray

After three plus years, the screen of my Ray was seriously scratched.
I got a replacement one from Aliexpress for 16 USD some time ago and have just found enough time and courage to install it.
I followed this disassembly guide, but with the slight modification suggested by Ιωάννης-Πάρις in the first comment below the video.
All went well though there are bits of glue coming out at the edges here and there :-)
I prolonged the useful life of the device by a year or two, not too bad.

Sunday, December 13, 2015

Which OpenWRT version to use?

If you want a relief from the never-ending stories about flaws in router firmware and the incompetence of vendors to deliver fixes, OpenWRT is about the only relatively sane option and I've been using it for almost a decade, since the White Russian release.

OpenWRT has a development branch or trunk which may be a bit experimental and a Stable branch. A Stable branch is released about once a year. Their documentation says that basically anything beyond the current stable release is unmaintained. Is it really so? Well, it's open source, so it should be easy to find out.

Attitude Adjustment, or OpenWRT 12.09, has seen its last commit in September 2014, so it's dead indeed.
Barrier Breaker, or OpenWRT 14.07, on the other hand has seen an update five days ago, so it's certainly moving. But is it still fresh and safe to use? I did a quick and simple check to find out.

There were twelve security vulnerabilities (possibly more, but these were easy to filter) fixed in Chaos Calmer (OpenWRT 15.05, the current stable release) during its lifetime. I grepped for them in the Barrier Breaker sources and here's the result:



Fixed in
Chaos Calmer
Fixed in
Barrier Breaker
CVE-2015-3193 12/03/15 12/07/15
CVE-2015-3194 12/03/15 12/07/15
CVE-2015-3195 12/03/15 12/07/15
CVE-2015-5291 10/18/15 Still vulnerable!
CVE-2015-3143 07/12/15 Still vulnerable!
CVE-2015-3144 07/12/15 Still vulnerable!
CVE-2015-3145 07/12/15 Still vulnerable!
CVE-2015-3148 07/12/15 Still vulnerable!
CVE-2015-3153 07/12/15 Still vulnerable!
CVE-2015-3236 07/12/15 Wasn't vulnerable
CVE-2015-3237 07/12/15 Wasn't vulnerable
CVE-2015-1793 07/09/15 07/09/15

There's a bunch of security issues lurking in the code unfixed.
It looks like an older release may still get some support in the first few months after it's been replaced, but it's not really wise to delay the update.