This entry is not really about computers, technology, or other work-related topics, but more about a hard-hack that I wanted to try for a while. How to make a kilt !!!

After a bit of duck-ducking, I decided to follow this excellent tutorial. At first sight the entire process seems a bit long, but you will realize that after the first read, that everything boils down to 3 steps: measure, fold and pin, sew.

For the measure part, I’ve the impression that the formula that is given in the instructable (waist/3*8+1) is a bit short for my comfort and taste. This is the size for the internal apron, the folded part that goes all around your left hip, back, and right hip, and the front apron. My suggestion would be to make the inner apron a bit longer then the front apron. This way the kilt will feel in my opinion more comfortable and it will envelop you body completely.

For the fold and pin part, you just need a bit of patience and a ruler. Put the pins parallel to the folding as in the instructable and not perpendicular. This will help you later when sewing everything.

The sewing … If you know how to use a sewing machine, this is going to be a piece of cake. Otherwise, well, I spent more time troubleshooting the machine then sewing the kilt. I broke a few needles in the process and learned how to thread the machine with my eyes blindfolded. Not to mention that you have to learn how to disassemble this machines in a thousand parts to understand how the thread got stuck. It was fun. A lesson that I’ve learned is that a sewing machine works much better in the morning than late at night when you are tired and sleepy. Really !

Other then that, it was a fun experience. Maybe I’ll make another one to commit this skill to mind. Maybe I’ll run a kilt making workshop at the next debconf :)

• Attachment 0
• Attachment 1

It’s true, sometimes the title of my post try to be more as web search engine-friendly as possible…

Yesterday I was very unhappy of the new behavior of awesome. All of the sudden windows were not receiving focus automatically on screen change, forcing me to either use the mouse of to do some other keyboard action. so for the first time I decided to have a look at the awesome config file. At file I’ve to admit it’s a bit intimidating. I don’t know a word of lua and it’s syntax is not really intuitive.

First a word about my setup. I use xfce4 + awesome. I don’t want thunar of xfcedestop running and I don’t want the wibox bar hiding somewhere…

I’ll show highlight few chunks of the file. If interested, the whole file is attached to this post. I wrote only a small function, everything else are bit and pieces that I found on the net.

A bit debugging code that is actually very handy when trying to understand what is going on :

if awesome.startup_errors then
    naughty.notify({ preset = naughty.config.presets.critical,
                     title = "Oops, there were errors during startup!",
                     text = awesome.startup_errors })
end

do
    local in_error = false
    awesome.add_signal("debug::error", function (err)
        -- Make sure we don't go into an endless error loop
        if in_error then return end
        in_error = true

        naughty.notify({ preset = naughty.config.presets.critical,
                         title = "Oops, an error happened!",
                         text = err })
        in_error = false
    end)
end

A small function to raise one window in each screen when I move left or right. This is actually not what I want, but it is better then nothing. What I’d really like is to raise the window under the mouse pointer. However the function awful.mouse.client_under_pointer () does not seem working as expected… so this is something I want to fix sometimes in the future.

function myautofucus() 
   awful.client.focus.byidx(1)
   if client.focus then client.focus:raise() end
   local c = awful.mouse.client_under_pointer ()
   if c then client.focus = c; c:raise() end
end

-- {{{ Key bindings
globalkeys = awful.util.table.join(
    awful.key({ modkey,           }, "Left",   function () awful.tag.viewprev() ; myautofucus() end ),
    awful.key({ modkey,           }, "Right",  function () awful.tag.viewnext() ; myautofucus() end ),

And then the rule I use to adjust different type of program I currently use. To get the class of a window you can use xprop .

-- {{{ Rules
awful.rules.rules = {
    -- All clients will match this rule.
    { rule = { },
      properties = { border_width = beautiful.border_width,
                     border_color = beautiful.border_normal,
                     focus = true,
                     keys = clientkeys,
                     buttons = clientbuttons,
                     size_hints_honor = false
                 } },
    { rule = { class = "MPlayer" },
      properties = { floating = true } },
    { rule = { class = "pinentry" },
      properties = { floating = true } },
    { rule = { class = "gimp" },
      properties = { floating = true } },
    { rule = { class = "Chromium" },
      properties = { tag = tags[1][8],
                     floating = true } },
    { rule = { class = "Iceweasel" },
      properties = { tag = tags[1][2] } },
    { rule = { class = "Pidgin" },
      properties = { tag = tags[1][7],
                     floating = true } },
    { rule = { class = "Skype" },
      properties = { tag = tags[1][9],
                     floating = true } },
    { rule = { class = "Orage" },
      properties = { floating = true } },
    { rule = { class = "Wicd-client.py" },
      properties = { floating = true } },
    { rule = { instance = "plugin-container" },
        properties = { floating = true } },

}

And this small bit is to remove the wibox :

a = awful.wibox()
a = nil

All in all lua is a nice language and awesome is a really flexible WM. Having the possibility to script its configuration file gives you unlimited space to experiment and automate boring and repetitive actions. Very nice :)

• Attachment 0

I had for a while a tenvis mini319W network camera. this camera is the usual consumer Chinese product, built on the cheap, bad packaging and sold in low end computer shops. Anyway, it was a cheap and dirty solution for a project of mine and despite everything it does the job ok.

The Tenvis mini319W is actually the same as foscam FI8918W and when I say the same, it means different casing, but same exact identical board. It’s just a re-branding. For some reason there are a lot of clones of this model. To stress even more the fact that they are actually the same product I even downloaded the firmware from foscam and flashed my tenvis without problems. The correct firmware to use is lr_cmos_11_37_2_46.bin that is the zip file you can download from the foscam website. I assume that the foscam firmware is more up-to-date, and for the moment the firmware is working fine. The two relevant links : http://www.tenvis.com/web/firmwaredownload.html  http://www.foscam.com/down3.aspx

Here there is a long list of cameras that are compatible with the same firmware. I spent all this time on this gadget just because the tenvis model is not included in this list …

After a fair amount of time learning how to unpack the firmware, I found this blog that has all the information and tools to turn this camera in an open camera. There is also a project called openipcam that focus on this family of products. You can find there all the information that I managed to figure out in the mean time. I thing this wiki is the main source of information about foscam hw/sw.

This is a walk through of all the things I’ve learned this morning about this camera.

First steps to analyze a proprietary firmware

The easier thing you can do while approaching a binary you don’t know if to look at it. After a few try with hexdump I quickly realized that the format wasn’t anything I had seen before. Since I didn’t have enough info to duckduck, I end up asking on irc for help. Shortly after I stumbled on the excellent binwalk a nice tool to unpack firmaware images.

$binwalk lr_cmos_0_37_2_36.bin 

DECIMAL     HEX         DESCRIPTION
-------------------------------------------------------------------------------------------------------
20          0x14        Zip archive data,  at least v2.0 to extract
712036      0xADD64     romfs filesystem, version 1 size: 1094448 bytes, named rom 4cfcea76.
715668      0xAEB94     BFLT executable  version 4,  code offset: 0x00000040,  data segment starts at: 0x00011170,  bss segment starts at: 0x00013760,  bss segment ends at: 0x000150E8,  stack size: 10240 bytes,  relocation records start at: 0x00013760,  number of reolcation records: 693,  ram gzip
[...]

This tool definitely got me started. Analyzing the output it is easy to guess that the first part is a zipped kernel, the second part, and more interesting, is the romfs image. I wanted to know if it is possible to have a shell console on the device, so I focused immediately on the fs image. To extract and mount the image, you just need to get it from the binary blob with dd and the just mount it.

dd if=lr_cmos_0_37_2_36.bin of=romfs.bin bs=1 skip=712036
mkdir test
mount -o loop romfs.bin test/

so far, so good. This is what we got in the image :

test/bin$file *
camera:         BFLT executable - version 4 ram gzip
dhcpc:          BFLT executable - version 4 ram gzip
dhcpcd:         BFLT executable - version 4 ram gzip
dhcpd:          BFLT executable - version 4 ram gzip
fcc_ce.wlan:    POSIX shell script, ASCII text executable
ifconfig:       BFLT executable - version 4 ram gzip
init:           ASCII text
iwconfig:       BFLT executable - version 4 ram gzip
iwpriv:         BFLT executable - version 4 ram gzip
mypppd:         directory
route:          BFLT executable - version 4 ram gzip
rt73.bin:       data
sh:             BFLT executable - version 4 ram gzip
wetctl:         BFLT executable - version 4 ram
wpa_supplicant: BFLT executable - version 4 ram gzip

So there is definitely no way to access remotely to the camera… However at this point, I started to suspect that there were few too many similarities with the foscam firmware… and once you have to right keyword, you can find almost everything on the internet.

Shortly after this revelation I ended up on this post and a minute later on the source code.

From here on, it was easy : somebody else already did all the hard work. Unpacking the firmware with fostar is a breeze:

$fostar -u lr_cmos_0_37_2_36.bin 
***      REMEMBER! ALWAYS KEEP A BACKUP OF YOUR ORIGINAL FIRMWARE       ***
*** I AM NOT RESPONSIBLE FOR YOU TURNING YOUR CAMERA INTO A PAPERWEIGHT ***
***              USE OF THIS SOFTWARE IS AT YOUR OWN RISK               ***
***                                                                     ***
***           If you don't agree to this, press 'Ctrl+C' now.           ***

Extracting linux.zip (712016 bytes)...
Extracting romfs.img (1094656 bytes)...

$unzip linux.zip 
Archive:  linux.zip
  inflating: linux.bin               

$strings linux.bin | grep -E "Linux version"
Linux version 2.4.20-uc0 (root@maverick-linux) (gcc version 3.0) #1452 

Now I know the architecture and in theory with this info I could recreate the build environment to add more binaries to the rom. Then the Web interface is in a different binary blob. To extract :

$./fostar -x /var/tmp/mini_1.2.2.18.bin /var/tmp/webUI
***      REMEMBER! ALWAYS KEEP A BACKUP OF YOUR ORIGINAL FIRMWARE       ***
*** I AM NOT RESPONSIBLE FOR YOU TURNING YOUR CAMERA INTO A PAPERWEIGHT ***
***              USE OF THIS SOFTWARE IS AT YOUR OWN RISK               ***
***                                                                     ***
***           If you don't agree to this, press 'Ctrl+C' now.           ***

Disassembling firmware file '/var/tmp/mini_1.2.2.18.bin' to '/var/tmp/test2/'
Extracting /admin.htm (1153 bytes)...
Extracting /admin_content.htm (4519 bytes)...
[...]

fostar has also built in the capability to repack the image, giving the possibility to fix, hack and modify the interface (or the rom image, if you want to go thought the hassle of cross compiling your tools.

These cameras can also be connected via a jtag (serial cable) interface. I’ve a small jtag to usb cable and I want to try this next…

These are other few interesting links related to firmware analysis in different contexts that I found and read along the way.

• http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/
• http://en.wikipedia.org/wiki/ZIP
• http://aluigi.altervista.org/mytoolz.htm
• http://0entropy.blogspot.fr/2011/08/firmware-reverse-engineering.html
• https://sites.google.com/site/shihsung/rc32xxx-soc/analyze-firmware
• http://code.google.com/p/firmware-mod-kit/source/checkout
• http://www.networkworld.com/community/node/41672

If you use iceweasel / firefox and privoxy , you might want to let privoxy do its job more effectively and to remove all ads from your webpages. In the past I’ve used the adblock firefox extension, but I’ve the gut feeling that letting privoxy handle the ads removal might be more effective.

There is a very nice script here to convert adblock plus rule to privoxy rules. Using it, it is very easy :

$sudo apt-get install --solver aspcud privoxy
[...]
$sudo /var/tmp/privoxy-blocklist.sh
[sudo] password for abate: 
Processing https://easylist-downloads.adblockplus.org/easylistgermany.txt ...

Downloading https://easylist-downloads.adblockplus.org/easylistgermany.txt ...
.. downloading done.

Modifying /etc/privoxy/config ...
... modification done.

Installing new config ...
... installation done


Modifying /etc/privoxy/config ...
... modification done.

Installing new config ...
... installation done

... https://easylist-downloads.adblockplus.org/easylistgermany.txt installed successfully.

Processing http://adblockplus.mozdev.org/easylist/easylist.txt ...

Downloading http://adblockplus.mozdev.org/easylist/easylist.txt ...
.. downloading done.
... http://adblockplus.mozdev.org/easylist/easylist.txt installed successfully.

The only thing left to do it to point your web browser to provoxy and have fun on your new clean internet.

Update

After one day of use, I’ve to say that the adblock extension of firefox is still neede for few website. it seems privoxy is not that good at blocking pop-ups and other more subtle trick to display advertisement . For the moment i’ll use both…

If you have an intel sound card and you are concerned about battery life, probably you have seen this in the powetop output…

100.0%                      Device         Audio codec hwC0D0:

Conexant

After much duck-duck-ing around I found this enlightening comment on the lesswatt mailing list. It turns out that to enable power management on this device, the device must be open first. Something like

echo -n | aplay

in your rc.local script should do the trick.

hopefully this will give me few more minutes of battery time. Still no clue for the other device :

100.0%                      Device         Audio codec hwC0D3:

Intel

This page has plenty of good tips, most of them already integrated in the laptop-mode package in debian…

I added a couple of lines to my /etc/sysfs.conf file :

module/snd_hda_intel/parameters/power_save=1
module/snd_hda_intel/parameters/power_save_controller=Y

but the Audio codec hwC0D3: Intel is still there hanging with 100% :(