I was messing around with adblock on my OpenWRT router. While trying to get it to work I got the following error:
sha256sum: not found

After a bit of digging around, I found that the sha256sum binary is in the coreutils-sha256sum package.
So installing on OpenWRT over SSH goes like this:
opkg install coreutils-sha256sum

I upgraded my Raspberry Pi to a newer kernel and updated the firmware with the following commands:

sudo apt-get update && sudo apt-get upgrade
sudo rpi-update
sudo reboot

After this my pilight couldn’t send anymore using the lirc_rpi module. Al lot of resources mentioned a new device tree and stuff, so I added the following to my /boot/config.txt file:

# Uncomment this to enable the lirc-rpi module
dtoverlay=lirc-rpi,gpio_out_pin=22,gpio_in_pin=18

This caused the lirc_rpi module to be loaded and I could receive data using the pilight-raw command. But sending still wouldn’t work.

After lots of time and effort I found the culprit. The new module seems to have enable softcarrier by default. Also autosensing didn’t work always as intended. So I changed the lines in my /boot/config.txt to the following:

# Uncomment this to enable the lirc-rpi module
dtoverlay=lirc-rpi,gpio_out_pin=22,gpio_in_pin=18,sense=0,softcarrier=off

Now everything works as expected!

Please let me know if this helped you to solve your problem.

iodineI’ve had some troubles getting Iodine-server to work under CentOS 7. So iv’e decided to write an article how I’ve managed to get it to work.

This instruction is based on a setup using iptables instead of firewalld, because I run iptables on all my servers since forever.

DNS setup

For iodine to work there are two records required. An A-record and an NS record. I’ve used the same naming as the iodine documentation, to keep it as simple as possible.
First add an A-record with the name t1ns that points to the ip of your server that will run the iodine server. The ip used here for the example should be replaced by your ip.
A: t1ns.<<yourdomain>> → 374.263.291.194

Then add an NS record with the name t1 that points to the A-record you’ve just made;
NS: t1.<<youdomain>> → t1ns.<<yourdomain>>

That’s all there is required for iodine to work with your domain.

Installing iodine

Firstly, make sure the EPEL repository is installed:
yum -y install epel-release

Then install iodine-server:
yum -y install iodine-server

Next is configuring iodine by editing /etc/sysconfig/iodine-server.
Make sure the line that starts with OPTIONS look something like this:
OPTIONS="-f -c -P <<yourpassword>> 10.1.1.1 t1.<<yourdomain>>"
Replace <<yourpassword>> with the password you wish to use, and <<yourdomain>> with the domain you are using for iodine.

Then, start iodine-server and enable it at boot:
systemctl start iodine-server
systemctl enable iodine-server

Configure traffic routing

Allow DNS and NAT traffic trough iptables:
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADE
iptables -t filter -A INPUT -p udp -m multiport --dports 53 -j ACCEPT
iptables -t filter -A INPUT -i dns0 -j ACCEPT
iptables -t filter -A OUTPUT -o dns0 -j ACCEPT
iptables -t -A OUTPUT -p udp -m multiport --dports 53 -j ACCEPT
iptables -t filter -A FORWARD -i dns0 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED -j ACCEPT

And save the new ruleset:
iptables-save > /etc/sysconfig/iptables

Next, allow ipv4 packet forwarding and restart the network service to apply this change:
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/ip_forward.conf
systemctl restart network

Conclusion

That’s it. You should be able to connect with iodine to your server by using the address t1.<<yourdomain>>.

An Android client that seems to work pretty good and I use is AndIodine, and is available via the F-Droid catalogue.

Please leave a comment if this post was helpfull in any way.

When I tried to compile my own Android ROM, I got the following error:

CHK     include/linux/version.h
target Executable: skia_gm (/media/ssd/buildout//target/product/i9100/obj/EXECUTABLES/skia_gm_intermediates/LINKED/skia_gm)
target Executable: skia_test (/media/ssd/buildout//target/product/i9100/obj/EXECUTABLES/skia_test_intermediates/LINKED/skia_test)
target Executable: test-opengl-configdump (/media/ssd/buildout//target/product/i9100/obj/EXECUTABLES/test-opengl-configdump_intermediates/LINKED/test-opengl-configdump)
CC      scripts/mod/empty.o
/bin/sh: 1: /home/ted/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc: not found
make[4]: *** [scripts/mod/empty.o] Error 127
make[3]: *** [scripts/mod] Error 2
make[2]: *** [scripts] Error 2
make[2]: *** Waiting for unfinished jobs....

The problem was that the arm toolchain wasn’t installed. After installing the toolchain compiling succeeded.

Installing the toolchain can be done with the following command:
git clone https://android.googlesource.com/platform/prebuilt

After that, run the following command to add the toolchain to the PATH variable:
export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH

Compiling should now succeed without the previous error.

I’ve found this information on http://source.android.com/source/building-kernels.html, a very helpful information source for Android development.

If you own a shared hosting server, you probably want to keep the /var/log/messages file as clean as possible, to make searching for errors as easy as possible.

One of our web servers had a messages file filled with Drupal errors and warnings. It al seemed to come from one site.
After a bit of searching, it seemed the syslog module in Drupal was enabled. There are two solutions to this annoyance. You can disable the syslog module in the database used by this site, or make syslog log all Drupal errors to a separate file.

Database solution

The most easy method to check and disable the syslog module is disabling this module in the database as follows:

Checking if the module is enabled:
SELECT * FROM system WHERE name='syslog';
If the status column is 0, the module is disabled, in case of a 1 the module is enabled.

To disable the module:
UPDATE system SET status='0' WHERE name='syslog';

And to check if the module is really disabled:
SELECT * FROM system WHERE name='syslog';
The status column should now say 0.

Separate log solution

Create the file /etc/rsyslog.d/90-drupal.conf with the following content:

# drupal logging
if $programname == 'drupal' and $syslogseverity <= '6' then /var/log/drupal.log if $programname == 'drupal' and $syslogseverity <= '6' then ~

That's it. There should be no more Drupal messages in the /var/log/messages file.