Talk:Script for theft alarm using HDAPS

Wonderful idea! And works perfectly on my T43p, scared the cat away. ;)

--spiney 20:35, 12 Nov 2005 (CET)

---

Good, so it's at least a cat deterrant! A friend of mine had a nasty incident involving a laptop and a cat... BTW, I'm the author (identifed by IP address again due the usual ThinkWiki autologin flakiness).

--Thinker 20:52, 12 Nov 2005 (CET)

---

I had to tweak the line that reads the position file. My position file has - numbers in it for some reason, so: m/^\(-(\d+),-(\d+)\)$/ or die "Can't parse $pos_file content\n";

After that change it works great. It scared the dogs away here. ;) --nirik 21:24, 12 Nov 2005 (CET)

---

Fixed. Which ThinkPad model, BTW?

--Thinker 21:44, 12 Nov 2005 (CET)

---

Cool. Excellent. ;)

T42p here.

--Nirik 21:45, 12 Nov 2005 (CET)

---

I love it! Great contributions, Thinker!

Of course, it is more proof-of-concept tough, as a thief can simply hit the "mute" button, or carry an old headphone plug with the actual headphones chopped off and stuff this quickly into the audio out jack. Don't leave your laptop unattended :) :)

--Gsmenden 18:06, 28 Nov 2005 (CET)

---

Thanks! About muting, I'm not sure the mute button will work (I reset the mixer volumes every second), but the thief can certainly power off, or suspend, or pull out the AC and battery. But my hope is that the casual, uninformed laptop-snatcher will trigger the alarm for at least a few seconds, and if you're just down the hall or there are other people nearby, that's probably enough to save your laptop. Not as good as a real lock+alarm, but better than nothing, and pretty convenient when autoactivated by the screensaver ($use_kde=1).

--Thinker 01:40, 29 Nov 2005 (CET)

---

someone asked if it's possible to watch out for gnome-screensaver. - it is, using dbus-monitor (like explained on the gnome-screensaver faq page).

the following perl script

my $cmd = "dbus-monitor --session \"type='signal',interface='org.gnome.ScreenSaver',member='SessionIdleChanged'\"";

open (IN,"-|", "$cmd");

while (<IN>) {
   if (m/^\s+boolean true/) {
       print "screensaver is now active";
   } elsif (m/^\s+boolean false/) {
       print "screensaver is now inactive";
   }
}

will print when gnome-screensaver goes active

The ugly part is

1. You can only find out once gnome-screensaver is going active or inactive, but not if it's active when the scripts is started.

2. I don't really know how to check if there is new output in <IN>, because something like my $cmdline=<IN>; will hang until there is new output (like when the screensaver is going (in)active).

--Mcgiver 20:35, 12 Nov 2005 (CET)

---

Usefulness for head parking

Works great. Maybe we can the script for testing the disk park patches by Jon Escombe <lists@dresco.co.uk> -- User:Ozi23

---

You can use it for testing, but note that the specific algorithm used in this script (threshold on standard deviation of samples during last second) is optimized for the theft deterrent situation. It is highly unsuitable for the head parking application, since it reacts too slowly -- by the it will recognize the movement, the disk heads will have already crashed. For head parking you'd need a low-latency algorithm, and preferably an in-kernel implementation to allow frequeny low-overhead polling, reduce latencies, and avoid accidentally spinning the disk up when loading or swapping in userspace stuff needed to spin the disk down.

--Thinker 20:20, 14 Nov 2005 (CET)

---

It's even worse that I thought. Check out the IBM white paper - there's barely enough time to park the head, so in the Windows driver they're using some pretty fancy learning algorithm to deduce when movement deviates from "normal", to decide when to redefine "normal".

--Thinker 19:08, 22 Nov 2005 (CET)

---

Good news every one ..... Just kidding. I've found the hdapsd package which acts as a deamon for the hdaps and uses the kernel patch by Jon Escombe. I havent tested it but some people were able to get the protection system work. It seems to depend on the firmware of the harddrive. Its in early stage so be carefull.

http://lwn.net/Articles/154923/ (kernel patch) http://bugs.gentoo.org/show_bug.cgi?id=100167 (hdapsd)

---

Minor modifications

tp-theft.pl v0.33 is working fine here, but I have modified some parts:

• I made a change for kdesktop_lock since it is located in /usr/kde/<kde-version>/bin/ here (Gentoo-specific)
• I removed the check wether kdesktop is running. I start tp-theft.pl via inittab which will be up before I have logged in

-- satmd, 2005-12-25

What's Gentoo's way of finding out the KDE path? I suppose

my $bin = `which kdesktop_lock`;

won't work from an initscript because the PATH is not set up yet.

--Thinker 23:38, 25 Dec 2005 (CET)

With Gentoo

/usr/bin/env kde-config --exec-prefix --expandvars

returns /usr/kde/3.5 . That looks general useable to me. I do not use an initscript, but inittab ... with initscripts one could easily source /etc/profile or something.

-- satmd, 2005-12-25

Will an inittab script find kde-config, which is probably in /usr/kde/<kde-version>/bin/ too? And if so, won't which kdedesktop_lock also work?

--Thinker 00:56, 26 Dec 2005 (CET)

Did not work - both of them. Keeping my hardcoded value. -- satmd, 2005-12-26 06:09 CET

Is there a way do make something like this work on Windows?

see topic.

---

theoretically speaking yes, since the accelerometer must be readable in windows too.

But I doubt there is an easy way to find out how to read it.

You might want to decompile the ibm hdaps active protection script to find out.

--Mcgiver 20:35, 12 Nov 2005 (CET)

---

Debian/Ubuntu libsox dependencies

Just a little Debian/Ubuntu heads-up:

If you get this error:

sox soxio: Can't open output file `/dev/dsp': unknown file type `ossdsp'

...then try installing libsox-fmt-oss. This fixed the problem for me, on Debian Etch. I based this info off of an Ubuntu forum post... different problem, but the same error message: http://ubuntuforums.org/showthread.php?t=740612

--Andy Shank 14:38, 13 Oct 2008 (MST)

---

New Sox Version?

I got this error

sox formats: no handler for given file type `nul'

with current sox 14.2.0 in Debian unstable.

Replacing -t nul /dev/null with -t fixed it for me. I'm not changing the script because I guess the majority is still using older sox.

--Defiant 18:25, 23 April 2009 (UTC)

I have the same problem, but I don't understand your fix. sox -t -t ossdsp /dev/dsp synth 1.0 sine 2000-4000 sine 4000-2000 → sox formats: no handler for given file type `-t Kiraven 15:23, 1 May 2009 (UTC)

Any solution to this problem?

sigurd 18:00, 19 May 2009 (UTC)

I replaced -t nul /dev/null with -n, now, it's working. --Kiraven 10:48, 6 August 2009 (UTC)

Alcap 01:42, 30 Jan 2010 (UTC)

You also need to replace -w option with -2. Here's the working code as of 30/01/2010 with sox version 14.3.0 my $warn_cmd = "sox -n -t wav -s -2 -c2 -r48000 -t raw - synth 0.10 sine 2000-4000 sine 4000-2000 | aplay -q -fS16_LE -c2 -r48000"; my $alarm_cmd = "sox -n -t wav -s -2 -c2 -r48000 -t raw - synth 1.0 sine 2000-4000 sine 4000-2000 | aplay -q -fS16_LE -c2 -r48000";