Marquis WiFi Vergaderruimte 4 update failed.

I've tried everything, from ssh'ing, factory resetting with set-default, to manually upgrading with upgrade, etc.

Nothing worked. I thought I had a bunch of bad APs (and many had their warranty expire by a few weeks or months).

As a last resort, I decide to reach out to Ubiquiti's support. First line wasn't very helpful, but as the case was escalated, I've managed to recover and properly update the APs.

The trick is to ssh into the device and run the following code:

curl -fs https://dl.ui.com/firmwares/uap/jw/U6Rescue.sh | sh

The device will reboot and pop by up in the dashboard after 2-3 minutes. Then try to update again, and all should work.

Not really sure what's going on here but ...

Another 8 buildings connected (including outdoor WiFi in the park, and in the shared indoor spaces).

Zigbee is quite cool because it's a mesh network. As I used it before with my Philips Hue bulbs, I was eager to expand and play with Zigbee.

First thing first. Not all routers are equal. I've got these two smart power plugs as an example (Grey and Blue colour, v2 with HomeKit support) and they act weirdly. They don't seem to route sensors properly, and randomly turn off whatever is plugged in.

The one that seems to work reliably well is this orange Zigbee plug.

Compared to my bulbs (more on that here) the sensors do detect them the two aforementioned power plugs, and do connect, but generally little to no data flows. I'm not entirely sure what the issue is (bad antenna, bad routing software) but the consensus on the internet seems to be: add more routers, don't trust some routers (Ikea and Hue seem decent), and not all endpoints are very smart and pick the best router (so may need to repair or force it to join a specific router). Unlike WiFi, in this case it seems that more is better.

When setting up the network, it's also recommended to first set up and pair the routers and then the endpoints (battery-powered sensors).

And the network takes a while to stabilise (and all routes to be learned). Some people even suggest waiting one or two days for the dust to settle.

Moving routers screws up a lot, too. I've had sensors stop working (and refusing to pair again) after moving some routers and turning some off -- routers that weren't used by said sensors. So really odd stuff.

As always, with Aliexpress, it's very much unclear what the brand/model is, but according to Z2M, all three are TS011F, but two of the three are definitely different (has Apple Homekit support and the plugs are bigger).

The energy (kWh) and Power (W) reporting works well, though, on all three models.

Can see when a charger is plugged in, and charging a MacBook Air.

I'm buying EU plugs because I'll be relocating back to Europe in the next 6 months. So I'm slowly getting rid of my UK smart plugs and replacing them with EU plugs.

Note that these plugs are not approved for (official) sale in Belgium though: child safety is not up to spec and the grounding is not approved (i.e. needs to be a pin). 

Zigbee is quite cool because it's a mesh network. As I used it before with my Philips Hue bulbs, I was eager to expand and play with Zigbee.

I have several bulbs, including: Hue Iris, Hue Go, some random bulb, a reading spot, and Hue Play (3x).

My Home Assistant setup uses the Skyconnect. I've updated the firmware (on a Mac) to use Ember firmware as ezsp will be deprecated soon(™).

At the time of writing you can't update the firmware directly from HA just yet, you need another device.

As I had two Zigbee networks (one for Hue, and one for my sensors and Ikea bulb) it made sense to merge them (and have one less connected bridge): it would reduce interference, and the bulbs all act as a router, so that would greatly improve my network coverage and stability.

Generally speaking, it went quite smoothly: delete the devices in the Hue app (it factory resets them and puts them in pairing mode) and then pair them in Zigbee2Mqtt (I use that over ZHA).

However, my main issue was that my Zigbee bulbs were unreliable: it sometimes worked, but often it lagged or timed out. Especially when controlling multiple bulbs at once (such as a big room such as the living room) or sending multiple commands in sequence (on/off/on/off).

In hindsight, my sensors were unreliable as well: there was data missing, and it didn't properly broadcast/update every 5 minutes. I first thought it was just because they were cheap Chinese (TuYa) sensors using battery-power. If the temp or humidity didn't change enough, it wouldn't broadcast.

I often saw errors such as these in Z2M:

2024-05-26 22:29:02Publish 'set' 'state' to 'Hue Play Right' failed: 'Error: ZCL command 0x0017880104d89bc4/11 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed ({"target":29608,"apsFrame":{"profileId":260,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":11,"options":4416,"groupId":0,"sequence":110},"zclSequence":244,"commandIdentifier":11} timed out after 10000ms)'

But the annoying thing (in debugging, and thinking the network "needs to settle") was that it often worked just fine, and then randomly started breaking down/time outing when I thought it was finally solved.

I almost gave up and went back to a Hue bridge, when I asked for some advice on Discord. The reason was the channel...

First off: check the Zigbee channel of your Hue. It's likely 25. Z2M uses channel 11 by default.

There are 4 channels that are getting the least WiFi interference. These are called ZLL channels (whatever that stands for): 11, 15, 20, 25. However, it seems that 11 is quite terrible, and I would not recommend using it.

My Z2M sat on Channel 11 (which is Channel 1 for WiFi). I live in Singapore, in an apartment building, with a shit-ton of WiFi, hence the massive interference and lag on Zigbee.

Also, 2.4Ghz WiFi is generally 20Mhz channel width, whereas Zigbee is 2Mhz, so one WiFi channel overlaps many Zigbee channels. 

You can modify the channel (via the config file in /homeassistant/zigbee2mqtt/configuration.yaml) by adding the following and restarting the Z2M container:

advanced:
  [...] # there should already be a ton of things
  channel: 25

The problem with changing the channel, is that it requires repairing (some of) the Zigbee devices. And it's a total mess to repair Hue bulbs once they are no longer on a Hue bridge.

There's no need to remove the devices from Z2M as that will wipe their configs (I believe). It's possible that removing the devices from Z2M will put them in pairing mode again (for Hue bulbs, see below) but I couldn't get a confirmation.

Ikea has the 6x power off/on sequence that resets them, but Hue dropped support for something similar in some firmware upgrade (why?!?!).

TouchLink is another option, but that didn't work for me at all.

Some Hue bulbs can be reset by long pressing (30-60seconds) the power button (for example the Hue Go), but what worked best for me is pairing them again on the Hue bridge using the serial (force pair), deleting them again, and pairing on Z2M.

However, I didn't have the serial of two bulbs: one Hue Play has the label missing, and the Hue Iris didn't have any label at all. I thought I would be forced to go and purchase a Hue dimmer/remote control (that comes with TouchLink and allows resetting the bulbs)...

However, suddenly, after an hour or two of messing around, the Hue bulbs that weren't repaired just started working again.

So it seems that if they are disconnected from their bridge for a while, they start changing channels until they find the bridge again. I guess there's a chance, with enough patience, that I didn't have to repair my Hue bulbs (not sure about Ikea, and I would definitely not trust my Chinese Power plugs and sensors to come back online).

The sensors are quite easily repaired (long press the pairing button or pinhole and done -- don't forget to set Z2M in Permit join)

Other stuff you can try if the range or network sucks can be found here.

However, if it kinda works, you better not mess with it... :)

The proxy config can be found here.

Be sure to modify the variables to match whatever you want to do. I'm using static IPs because auto discovery is unreliable (hostname.iot.internal).

You'll also need to add the !secret variables into the secrets.yaml file.

Note that there's an issue with Bluetooth and WiFi on single cores (i.e.: the ESP locks up as it can't do both at boot). The workaround is in that config file.

Use on single-core chips

On dual-core devices the WiFi component runs on core 1, while this component runs on core 0. When using this component on single core chips such as the ESP32-C3 both WiFi and ble_tracker must run on the same core, and this has been known to cause issues when connecting to WiFi. A work-around for this is to enable the tracker only while the native API is connected. The following config will achieve this:

esp32_ble_tracker:
  scan_parameters:
    continuous: false

api:
  encryption:
    key: !secret encryption_key
  on_client_connected:
    - esp32_ble_tracker.start_scan:
       continuous: true
  on_client_disconnected:
    - esp32_ble_tracker.stop_scan:

Esphome

To flash the Mi thermometer, use this flasher and the firmware from here.

Example output of the log (from Esphome in Home Assistant directly, but can be seen from the web interface as well):

You can then add the proxy (and the entities) in Home Assistant. It should update every couple of minutes (the Mi device updates every 5 or so minutes, the Proxy scans every channel every 3-ish minutes).

In the example above, I (at the time of writing) only have one Bluetooth sensor, but it should be quite trivial to add more. The hardest part is finding the right MAC address of the sensors... :)

# docker logs ipchanged
29-09-2023 - 11:26:35 - Logged in as @turtlebot:matrix.org
29-09-2023 - 11:26:35 - IP address for be.yeri.be is 94.105.123.126
29-09-2023 - 11:26:35 - IP address for sg.yeri.be is 58.96.238.208
29-09-2023 - 11:26:35 - IP address for industry.yeri.be is 78.23.172.72
29-09-2023 - 11:29:36 - IP address for be.yeri.be is 94.105.123.126
29-09-2023 - 11:29:36 - IP address for sg.yeri.be is 58.96.238.208
29-09-2023 - 11:29:36 - IP address for industry.yeri.be is 78.23.172.72

Includes a Docker container to keep it running.

I made it less noisy (i.e. won't talk when the IP didn't change) and as the IP of my DynDNS hosts hasn't changed yet, there's not much to see... ;)

The provided scripts have been updated on 16 Jul 2023. Specifically the SmartStrip part was not working as intended.

I've been a big fan of Betteruptime. I've started using it to monitor all my assets online (websites, DNS, ping, successful script runs) as well as my servers (using heartbeats).

I have a few Raspberry Pi's, and once in a while they hang (not sure why, maybe USB-to-SSD issues or something). Nothing too critical, but annoying.

I've plugged them all on TP-Link Kasa smart plugs to remotely restart them if I had to (once or twice a year).

Note, to confuse everyone, TP-Link also launched Tapo, which... competes with Kasa and is not compatible, but does the exact same thing... ¯\_(ツ)_/¯

After some Googling (actually Kagi'ing) I found out, there's a Python library that lets you control your smart plugs.

So, the idea was born to:

• Check Betteruptime heartbeats, if down, power cycle the smart plug
• Do this at most once per day (in case something else is causing issues)
• Betteruptime heartbeats manage when a device is marked as offline (i.e.: it expects a heartbeat every 5 minutes, but will only consider the device down if no heartbeats are received for 2 hours).
• The bulk of the code had to be written by ChatGPT. Let ChatGPT choose the language (it ended up being a mix of Bash and Python)
• Everything needs to run in Docker (using a cron, the Docker container doesn't daemonise)
• These run on Raspberry Pi's (but of course the RPi can't check itself: so RPi1 checks for RPi2, and vice versa. As these RPis are on different networks (my parent's home, my own home, etc) I had to enable "--net=host" in Docker run to get the correct routes from the host system, but you may not actually need this
• To top if off, sent an email (using Mailgun EU servers) to warn me something broke and it rebooted

So, after some fiddling (half an evening or so) the proof-of-concept worked.

I should probably throw this in a Git repo but shrug. I don't want to give the impression that I'll maintain this and provide support.

Dockerfile:

FROM python:alpine
RUN apk add bash curl jq
RUN pip3 install python-kasa
COPY heartbeat.sh kasa-api.py /
VOLUME /tmp/kasa/
CMD ["/heartbeat.sh"]

Python script kasa-api.py (this works with both smart strips and smart plugs):

import sys
import asyncio
from kasa import SmartPlug, SmartStrip

async def main():
	if len(sys.argv) != 4:
		print("Usage: python kasa-api.py type IP-address outlet-index")
		return

	device_type = sys.argv[1]
	ip_address = sys.argv[2]
	outlet_index = int(sys.argv[3])

	if device_type == "smartplug":
		await control_smart_plug(ip_address)
	elif device_type == "smartstrip":
		await control_smart_strip(ip_address, outlet_index)
	else:
		print(f"Unsupported device type: {device_type}")

async def control_smart_plug(ip_address):
	plug = SmartPlug(ip_address)

	try:
		await plug.update()

		# Retrieve the current state
		plug_state = plug.is_on

		# Turn off the plug
		await plug.turn_off()

		print(f"Turned off SmartPlug at {ip_address}")
		await asyncio.sleep(5)

		# Turn on the plug if it was previously on
		if plug_state:
			await plug.turn_on()

		print(f"Turned on SmartPlug at {ip_address}")
	except Exception as e:
		print(f"Failed to control SmartPlug at {ip_address}: {e}")

async def control_smart_strip(ip_address, outlet_index):
	strip = SmartStrip(ip_address)

	try:
		await strip.update()

		# Retrieve the current state of the specified child plug
		child_state = strip.children[outlet_index].is_on

		# Turn off the specified child plug
		await strip.children[outlet_index].turn_off()

		print(f"Turned off child plug {outlet_index} in SmartStrip at {ip_address}")
		await asyncio.sleep(5)

		# Turn on the child plug if it was previously on
		await strip.children[outlet_index].turn_on()

		print(f"Turned on child plug {outlet_index} in SmartStrip at {ip_address}")
	except Exception as e:
		print(f"Failed to control SmartStrip at {ip_address}: {e}")

# Run the asyncio event loop
asyncio.run(main())

heartbeat.sh -- with example devices. Be sure to fill in the variables (including hb, that's the heartbeat ID you can get from the Betteruptime URL and the IP or DNS hostname of the smartplug):

#!/bin/bash

API_KEY="BetterUptime API token"
BU="https://uptime.betterstack.com/api/v2/heartbeats/" # no need to change this

MAILGUN_API_KEY="Mailgun API token"
MAILGUN_DOMAIN="mg.you.com" # use your own domain

if [[ "$DEVICE" = tyr ]] || [[ "$1" = tyr ]]; then

	# Tyr
	device="Tyr"
	hb=1111
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartplug"
	plug_host="smartplug1.kasa.you.com"

elif [[ "$DEVICE" = mammoth ]] || [[ "$1" = mammoth ]]; then

	# Mammoth
	device="mammoth"
	hb=2222
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartstrip"
	plug_host="smartstrip1.kasa.you.com"
	plug_index=0 # plug 2 is rly plug 3 because the index counts from 0 to 2 and not from 1 to 3.

elif [[ "$DEVICE" = liana ]] || [[ "$1" = liana ]]; then

	# Liana
	device="liana"
	hb=3333
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartstrip"
	plug_host="smartstrip1.kasa.you.com"
	plug_index=1 # plug 2 is rly plug 3 because the index counts from 0 to 2 and not from 1 to 3.

elif [[ "$DEVICE" = eagle ]] || [[ "$1" = eagle ]]; then

	device="eagle"
	hb=4444
	bu="https://uptime.betterstack.com/team/1/heartbeats/$hb"
	plug_type="smartstrip"
	plug_host="smartstrip1.kasa.yeri.be"
	plug_index=2 # plug 2 is rly plug 3 because the index counts from 0 to 2 and not from 1 to 3.

else
	echo "Unknown device."
	exit 1
fi

url=$BU/$hb

send_alert() {
	MAILGUN_URL="https://api.eu.mailgun.net/v3/$MAILGUN_DOMAIN/messages"
	from="kasa@you.com"
	to="alert@you.com"
	subject="Smartplug power cycled: $device"
	body="rebooted device $device!"$'\n'"Kasa IP: $plug_host."$'\n'"$bu"

	# Send alert email
	curl -s --user "api:$MAILGUN_API_KEY" \
		"$MAILGUN_URL" \
		-F from="$from" \
		-F to="$to" \
		-F subject="$subject" \
		-F text="$body"
}

kasa_cycle() {
	echo "Betteruptime heartbeat ($hb) says the service for $device is down, restarting."
	python /kasa-api.py "$plug_type" "$plug_host" "$plug_index"
	# Update the last execution date in the file
	echo "$current_date" > "$file"
}

kasa_info() {
	kasa --host $plug_host
}

response=$(curl -sL "$url" -H "Authorization: Bearer $API_KEY")
status=$(echo "$response" | jq -r '.data.attributes.status')

if [[ "$status" == "down" ]]; then
	dir="/tmp/.kasa/"
	mkdir -p "$dir"
	file="${dir}${device}.txt"

	# Get current date
	current_date=$(date "+%F")
	# Check if the file exists
	if [ -f "$file" ]; then
		# Get last execution date from the file
		last_execution=$(cat "$file")
		# We only want to run this once every 24hrs. If a reboot doesn't fix it, something more
		# serious is going on and likely needs manual intervention. No point spam rebooting the device.
		if [[ "$current_date" != "$last_execution" ]]; then
			kasa_cycle
			send_alert
		else
			echo "Power cycle already executed today."
		fi
	else
		kasa_cycle
		send_alert
	fi
elif [[ "$status" == "up" ]]; then
	echo "Betteruptime heartbeat says the service ($hb) for $device is up."
else
	# this could happen if the heartbeat is paused.
	echo "Unknown status."
	kasa_info
	exit 1
fi

I run Docker with two scripts, a builder (rebuild.sh) and a file that runs it (start.sh). It should rebuild in case a docker cleanup script ran (and deleted dangling containers).

I run this as root and probably shouldn't, but yeah... That'll be for another lifetime.

Be sure to change the paths (/root/git/kasa-api) in both scripts.

rebuild.sh:

#!/bin/bash
cd /root/git/kasa-api # the path where this project exists

git pull > /dev/null

BASEIMAGE=`cat Dockerfile | grep FROM | awk '{print $2}'`
docker pull $BASEIMAGE
docker build -q -t kasa-api .
rm -f /tmp/.kasa/*.txt

start.sh:

#!/bin/bash

if [ -z "$1" ]; then
	echo "Missing device name."
	exit 1
fi

docker stop kasa-api 2> /dev/null
docker rm kasa-api 2> /dev/null

run_kasa() {
	DEVICE=$1
	docker run --net=host -v /tmp/.kasa:/tmp/.kasa --rm -e DEVICE=$DEVICE --name kasa-api kasa-api
}

if [[ $(docker image ls | grep kasa-api) ]]; then
	run_kasa $1
else
	cd /root/git/kasa-api
	/root/git/kasa-api/rebuild.sh > /dev/null
	run_kasa $1
fi

And that's pretty much it. I run this using with cron in /etc/cron.d/. For example (be sure to edit the parameter/device name/path):

#
# cron-jobs for kasa-api
#

MAILTO=root

*/15 * * * *	root	if [ -x /root/git/kasa-api/start.sh ] && [ -f /root/git/kasa-api/start.sh ]; then /root/git/kasa-api/start.sh tyr >/dev/null; fi

I'm sure there must be bugs in this ChatGPT generated code but... so far, it has actually worked.

It probably sucks, spies on you, does MitM attacks, breaks most video conferencing tools, and is generally not very stable... Also... Zero trust!

Add this function to your .bashrc or .zshrc (whichever shell you're using*):

func killwarp() {
	sudo launchctl remove com.cloudflare.1dot1dot1dot1.macos.warp.daemon
	sudo killall Cloudflare\ WARP
}

Open a new shell window (to reload your dot files), and type killwarp.

This will permanently disable Warp (until your Mac is rebooted; as it's most likely force installed/started by your admin). So just run this after every reboot.

(*) Find out with echo $SHELL.

The first thing I noticed was that ethX renamed to enXY.

To get back to the old naming scheme, you can fix this by adding the following in /etc/network/interfaces:

rename enX0=eth0
rename enX1=eth1

And reboot.

To allow a USG (Unifi Security Gateway) to reply to external (WAN) ping requests, do the following:

• Head to the Unifi dashboard -> Settings -> Firewall & Security
• Create a new rule
• Type: Internet Local
• Description: Allow Ping (Echo Request)
• Rule Applied: Before Predefined Rules
• Action: Accept
• IPv4 Protocol: ICMP
• IPv4 IMP Type Name: Echo Request
• Apply Changes -> wait ~2 minutes

That's it...

All this for Smokeping.

Most of my (non-track) light at home is smart using either a TP-Link Kasa smartplug or Philips Hue (and I want to avoid adding more brands, more apps, and more shit). However, Philips Hue is quite $$$ and not always all that easy to get in Singapore (shady retailers, limited stock, not many options).

I knew that Tradfri was technically compatible with the Hue Bridge, but never made the jump as I just wanted things to work (don't want to mess around with lights). Until today. Figured I may as well give it a go.

Surprisingly, everything worked out of the box. I had to do a factory reset (not sure if that's because I kept the light on for ~10 minutes before trying to set it up, or if this was a returned product as clearly the box had been opened before)...

• Turn on light
• Reset light by turning it off and on 6 times
• Open Philips Hue app and search/add light
• Tada... Should work

Side note: it requires a modern firmware (and I assume all lights being sold today have said firmware, but if for some reason you end up with old stock, you may need to update). To update you need the Ikea Bridge though (or... apparently the dimmers/buttons may work as well -- did not test).

All the controls are working as well (dimming, changing colours, etc).

First off, starting to use the smokeping.eu¹ domain that Bianco got 10 or so years ago instead of using weird URLs under superuser.one domain.

It's running on four nodes as we speak:

• a virtual machine on a colocation server in Leaseweb, Amsterdam, NL -> leaseweb.nl.smokeping.eu
• a RPi3 (+SD card, slowest of all), Telenet, Belgium -> telenet.be.smokeping.eu
• a RPi4, EDPnet, Belgium -> edpnet.be.smokeping.eu
• a RPi4, Starhub, Singapore -> starhub.sg.smokeping.eu

This is achieved using Smokeping in a docker container, Cloudflare tunnel and Cloudflare CDN/DNS.

1 Doesn't point at anything at the moment. To do later.

When we're travelling (read: holiday) she's carrying an old Lenovo ThinkPad 13 (great device!) just "in case" she needs to open AutoCAD and edit something minor or read the drawings/dimensions. But honestly, most of the time that device is turned off and dead weight.

But all the above is just an excuse to "I was bored, and I wanted to test something": can I use an old Raspberry Pi (zero W) to remotely wake her Intel NUC, and then use Tailscale to use RD on her iPad? Well, yes I can.

I completed this using:

• Tailscale to remote desktop from anywhere to home
• Cloudflare Tunnels, Access and DNS to have a web interface to wake the desktop
• A Linux device that's always on and in the same LAN, and that'll run a PHP script.

Prep work: enable WOL

First off: enable Wake-on-LAN (WOL) in the BIOS and in your Windows settings. This article explains it for Intel NUCs, but would be similar enough for most devices. The Device Manager pane looked different on our i5 NUC, but was close enough.

On Mac, you just need to enable it in the Energy preference pane, for Linux I have no clue. 🤷‍♂️

Second step: have a working Raspberry Pi (or any Linux device) in the same LAN. This device needs to be turned on 24/7, so use something that uses very little power.

I do have a more powerful RPi4 I wish I could've reused (running Docker and some other "serious" stuff; however it's currently in a different VLAN, and it's quite crucial the Linux device is in the same LAN as the device(s) you want to wake up), so I went with an old Raspberry Pi Zero W that was collecting dust (it used to run pwnagotchi).

On the Linux device, install etherwake. The command to run is quite simply etherwake aa:bb:cc:11:22:33 (= the ethernet MAC address of your device).

If this doesn't wake your desktop, something is wrong and there's no point continuing. Go and troubleshoot.

Install Tailscale and RD

On the (Windows) desktop and your iPad, install Tailscale. Login, and make sure it works by pinging from one to the other.

Then set up Remote Desktop on both (Windows, iPad). You should test and make sure you can properly connect using the LAN IP address and then the Tailscale IP address.

Fun fact: I create a DNS record for all my devices using Cloudflare DNS with the syntax of device-name.ts.yeri.be, so I don't need to ever remember IPs, and can easily ssh or ping devices without having to look up IPs. 

Fun fact side track: I actually have a dynamic script that runs (on Linux) and creates hostname.ts.yeri.be for the Tailscale IP, hostname.wg.yeri.be based on the Wireguard IP, hostname.lan.yeri.be based on the LAN IP. This dyndns script runs every so often and updates IPs if needed. All this is running using Cloudflare DNS and their API. Super convenient.

Nginx, php and etherwake

I'm a 80s kid, so I'll use dirty PHP to run this script. I'm sure I'll go straight to hell for this, but yolo.

Install nginx and PHP (no need for MySQL and other stuff).

etherwake requires root to run (because it needs root access to create a weird magic ethernet packet). Create a file in /etc/sudoers.d/etherwake and add this line:

www-data ALL=(ALL) NOPASSWD: /usr/sbin/etherwake

This will allow www-data (nginx/php) to run /usr/sbin/etherwake using sudo, without password.

In /var/www/html/ create an index.php file with:

<html>
<head><title>Wake on Lan</title></head>
<body>
<p>Wake up <a href="mycooldesktop.php">My Cool Desktop</a>
</body>
</html>

And a mycooldesktop.php (or whatever) file with:

<?php
$output = shell_exec('sudo /usr/sbin/etherwake aa:bb:cc:11:22:33 2>&1');
echo "<pre>$output</pre>";
?>
<p><a href="..">Back</a></p>

It ain't pretty -- but it gets the job done. 

And be sure to edit the MAC address to match your desktop's ethernet MAC address.

Cloudflare tunnels

Install Cloudflare Tunnel (via Zero Trust dashboard).

When creating a new tunnel, the dashboard will give you all needed commands to install the tunnel on your RPi -- but be sure to select the right OS/architecture (arm64? arm? armhf?).

And then point the tunnel to http://localhost. No need to mess around with SSL certs.

Lastly, set up Cloudflare Access (via the same Zero Trust dashboard): create a new application, and make sure only approved users can sign in (i.e.: using a pin code emailed to only approved emails).

You can try it yourself via wol.superuser.one. You won't get in. :)

Optionally, but recommended: lock down Nginx to only allow connections from localhost (127.0.0.0/8 and ::1) if using Cloudflare Tunnels, or Cloudflare IPs if using port forwarding with Cloudflare Access in front. 

To recap

• We used Tailscale to create a VPN network between the desktop and the iPad. The big benefit is that Tailscale works effortlessly across NAT networks without having to open ports,
• We used Cloudflare DNS so we don't need to remember hostnames :),
• We used Cloudflare Tunnels to make sure the RPi web interface is accessible across NAT (without port forwarding) and from anywhere,
• We used Cloudflare Acces and locked down access to the right people using ACLs,
• We used etherwake running on a RPi to wake up devices that are hibernating or turned off.

And that's it really.

PS: technically WoL works with WiFi, but when I enabled WoL on the WiFi adapter, the NUC refused to hibernate/sleep for more than a minute, and kept waking itself up. So, there seems to be some kind of trigger in my network that keeps waking it up. Also, not sure if WoL via WiFi would work if the device is turned off (as opposed to sleep or hibernate). I just ended up using ethernet. 

PPS: both Cloudflare Tunnels and Tailscale use Wireguard tech in the background, so that's really cool. 

The Hamburg Regional Court today ruled that they would not suspend an existing injunction against Quad9 in a case filed by Sony Music Germany. The case centers around Sony Music’s demand that Quad9’s servers located in Germany stop resolving DNS names of third-party sites which are claimed to have URLs that contain copyright infringements.

Unbelievable.

Also note "claimed to have". Not proven to have.

Knowing that Sony has not been very good at actually identifying copyrighted content, and they just throw stuff around to see what sticks.

And DMCA requests have done more evil than good...

Also, what will actually happen? Quad9 will move its DNS servers outside of Germany and/or people will use other DNS resolvers. Nothing get fixed, and users are punished with worse latency.

This summer, the Lithuanian government went public with an astounding finding. A Xiaomi phone sold in Europe — the Mi 10T 5G — could censor approximately 450 words and phrases, it said. The blocklist wasn’t active, but could be activated remotely. It was filled with political terms, including “Democratic Movement” and “Long live Taiwan’s independence.”

[...]

The accusations, which Xiaomi disputes, clarified just how fraught the West’s relationship is with China’s growing technology power. As China-based tech companies like Xiaomi and TikTok flourish, there’s still no playbook in North America or Europe to deal with their potential to censor or steer culture via algorithms.

“Western countries,” Abukevicius said, “are more and more reliant on technologies, and a big part of those technologies comes from countries which are not friendly, which we don't trust, and it poses risks.”

About a year ago I purchased myself an OpenWRT router to use on the plane and in hotels.

And so far I really like both the device and the Hong Kong based brand (launching new and updated products, and releasing relatively regular updates for older products). Pick a device that fits your needs (USB powered? LTE? Small form factor?).

The GL-AR750S aka Slate is fully customizable but runs a few nice things out of the box: WireGuard (with a physical button to turn it on or off), OpenVPN, shell access, Tor (requires the latest firmware), IPv6, DoH (Cloudflare only for now), multiple SSIDs (i.e. Guest WiFi), and more.

Oh and I specifically picked this version (compared to other or cheaper ones) because it had both 2.4Ghz and 5Ghz, as well as 3 Gbit ports (1x WAN, 2x LAN).

I use the device on flights, where I connect to the network once in the air, purchase WiFi or use iPass "for one device" and then connect to the interwebs behind my NAT-router from my iPad, phone(s), laptop(s), and even Shan's devices if she is travelling with me.

In hotels, I either connect it to the wired ethernet, if still available (tends to be more stable), or connect it to the guest WiFi and then connect my devices to the router: saves me from connecting to a new network and typing the room number and login/password/family name on every device. And once again hides the true number of connected devices; quite handy trick for those pesky hotels providing free access only to two devices.

Sure it takes a bit of setup every time: find a working USB port, sign in to the web interface, search for new networks if this is a new hotel or I haven't travelled on this airline, connect to said network, sign in with iPass, and optionally enable VPN)...

And once in a while some fiddling with VPN or DNS that's borking up or being blocked by overzealous firewalls.

Also, some in-flight entertainment USB ports don't provide enough power (and/or are often broken -- looking at you Lufthansa in economy) so be sure to carry a couple of these (US-plug works best) -- I've already forgotten one on my last flight from MUC-SIN on LH, but luckily I have pretty easy access to these.

If you travel a lot it's totally worth the money.

The answer is... Yes -- but...

So plugging it straight into the USB-C port of the keyboard doesn't do anything. I.e.: the dongle is not recognised, and for what it's worth the switch doesn't even light up to say a cable is connected. So that doesn't work.

But plugging it straight into the iPad works... The network switch lights up, the iPad (under Settings) gets a new option called "Ethernet" (which oddly shows you a selection of connected adapters first -- but I don't know how you can have more than one). Clicking through you see the same options as you would for your WiFi network: IPs, DNS, etc.

Tadaaa!

I used an adapter from work, a Belkin, and I believe it's the same one that's being sold on the Apple Store. I don't know if any dongle will work though (driver-wise and stuff).

Probably not that useful but good to know.

Yesterday I finalised the sale of 0x04.com.

My company in Singapore was called 0x04 pte. ltd. and to avoid any confusion I've renamed to su1 pte. ltd. su1 standing for Superuser.one. 🤷‍♂️

The culprit is how EdgeOS deals with its hosts file. Basically it just keeps all the old hosts added and just adds a new line at the end of the file.

NextDNS searches for the first valid entry in that file, which is always going to be an older record.

So the simplest solution I found was the turn off hostfile-update every so often. This clears the hosts file.

So ssh into the device, run configure, and then run these commands:

set service dhcp-server hostfile-update disable
commit
set service dhcp-server hostfile-update enable
commit
save

Update 22 Jun '23:

Be sure to restart NextDNS, or it won't actually publish the up-to-date client hostnames.

sudo /config/nextdns/nextdns restart

Most of this can be copied from the amd64 post -- with a minor change for making it work on RPi4. This is the full git repo (including both rpi and amd64).

The main difference is in the run.sh file. The installation is a bit different and we'll need to install the Raspberry Pi kernel headers.

WireGuard is also installed from testing instead of Debian backports.

Note that for older RPi's (ie gen 1) you'll need to compile from scratch.

The solution is to manually update the package from 2.6.2 to 2.6.4. Find your NAS architecture and then download (bottom of the page) the right binary and manually install it.

Note that you need to stop the Resilio Sync service running (manually stop it via Package Center) before uploading the package and installing it.

Once done, don't forget to manually start the service again.

Resilio Sync GUI will be at <NAS IP>:28888/gui/.

The howto guide to manually update the package can be found here.

Setting up dkms (2.6.1-4) ...
Setting up wireguard-dkms (1.0.20200429-1~bpo10+1) ...
Loading new wireguard-1.0.20200429 DKMS files...
It is likely that 4.19.0-8-cloud-amd64 belongs to a chroot's host
Building for 4.19.0-8-amd64 and 4.19.0-8-cloud-amd64
Building initial module for 4.19.0-8-amd64
Error! Bad return status for module build on kernel: 4.19.0-8-amd64 (x86_64)
Consult /var/lib/dkms/wireguard/1.0.20200429/build/make.log for more information.
dpkg: error processing package wireguard-dkms (--configure):
 installed wireguard-dkms package post-installation script subprocess returned error exit status 10
Setting up build-essential (12.6) ...
Setting up libalgorithm-diff-xs-perl (0.04-5+b1) ...
Setting up libalgorithm-merge-perl (0.08-3) ...
dpkg: dependency problems prevent configuration of wireguard:
 wireguard depends on wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 0.0.20191219); however:
  Package wireguard-dkms is not configured yet.
  Package wireguard-modules is not installed.

dpkg: error processing package wireguard (--configure):
 dependency problems - leaving unconfigured
Processing triggers for systemd (241-7~deb10u3) ...
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 wireguard-dkms
 wireguard
E: Sub-process /usr/bin/dpkg returned an error code (1)

The solution was to install bc. Seems like Debian is not pulling the right dependencies. I'll be adding it to my Dockerfile.

So I am running two WireGuard servers -- one on a Raspberry Pi 4, and one in an amd64 virtual machine. This post will be about getting WireGuard working on amd64 in a Docker container.

As this container rarely get rebuild, I am running unattended-upgrades inside the container to make sure security updates are applied.

I am also running Bind9 to act as a caching DNS server inside the container. Ideally this should be running from its dedicated container but that makes everything more complicated and not worth it for what I am trying.

I am also

The public repo that acts as a proof of concept can be found here.

start.sh -- this file starts (or restarts) and builds the container. It will also create the files as needed, set the forwarding DNS server, etc.

Dockerfile -- the example will start a basic container based on debian-slim, set up the port forwarding, install the tools we need, and copy over the configs

run.sh -- this file will be executed after the container has been built. We need to install WireGuard from this file or it will fail due to the volume not being mounted and not having the right params.
This will also start the named (bind9) server.
I manually set ip address add dev wg0 10.200.200.1/24 because using Address in wg0.conf caused issues. I haven't recently tested if that's still the case.

named.conf.options -- pretty standard bind9 config file; I want to be in control of my forwarding server because I am using NextDNS and want to apply a different config.

And of course your wg0.conf.

Running docker exec wireguard wg should give details about your connected hosts.

I've been running WireGuard for a few months now and I've been loving it.

I first started using it about a year ago when in China — OpenVPN was once again being actively blocked and it was driving me nuts. Overnight I set up a DigitalOcean server in Singapore and ran WireGuard from it — both my phone and laptop were able to actively bypass the GFW and (at that time) surf the internet freely once more. As WireGuard gains popularity, I am sure the GFW will start detecting it — it's a quiet but not a stealthy protocol.

Since then I've dug quite a bit deeper in WireGuard and am really looking forward to what it's going to bring.

WireGuard differentiates itself to be an extremely simple VPN server (which can make getting started and debugging a bit more challenging) — but it wants to seamlessly work together with existing tools. One of the main features still missing is for example running a DHCP server on the server and dynamically assigning IPs (like oVPN does).

It's also pretty cool because any node can both be a server and a client at the same time. In my setup I am running two servers: one running at home in Singapore on a RPi4 (1Gbit fiber connection) and one on a virtual machine in Amsterdam (1Gbit as well). The RPis at my parents are connected to the server in Amsterdam, my iPad and phones are connected to the server in Singapore. If I am in Europe I might switch over and let my iDevices connect to the AMS server instead.

The example above clearly shows speed gains by cloaking the traffic in UDP packets. The shared folder has only two nodes (sender and receiver) and shows several big files being transferred from Amsterdam to Singapore. Resilio Sync uses the Bittorrent protocol, something ISPs generally hate and tend to slow down as much as they can — thanks Starhub.

Wireguard also allows the client to decide what to route through the server: only the VPN LAN traffic, or a whole subnet, or 0.0.0.0/0? So for my iPhone I for example route all traffic through VPN to avoid hotel/airport/... WiFi's to mine/log/scan my data. For my laptop I have two configs, one to only connect to the LAN, but another that routes all my traffic through the VPN if I want to avoid exposure or circumvent censoring.

Note that I am not running WireGuard to remain anonymous and I'll definitely leak some information — just trying to minimise and remain in control of what I leak. This is not a Tor replacement.

Playing around with Docker I saw some Smokeping image and that made me want to set it up again.

I'm running Smokeping on my server in Amsterdam (Leaseweb colo): smokeping.rootspirit.com.

At home, in Singapore, I am also running it on a Raspberry Pi 4: smokeping-sg.superuser.one.

Note that this is actually the same config used on both, as the RPi and server are on the same WireGuard network that works out nicely.

This is my docker run command to start it up:

docker run --name=smokeping --hostname=smokeping -e PUID=1000 -e PGID=1000 -e TZ=`cat /etc/timezone` -d -p 8000:8000 -v /srv/smokeping/config:/config -v /srv/smokeping/data:/data --restart unless-stopped --network 0x04 linuxserver/smokeping

Be sure to create the needed paths, and I am running it in my specific network 0x04. Change (or remove) --network 0x04 to something that works for you.

Shell servers... so 2005. I remember in the good old IRC days people asking for (free) shell servers to run their eggdrop and stuff. OMG am I getting old? Anyhow...

I ssh quite often. I manage quite a few servers (~15?) and routers that require me to login and do some random stuff. I also work on a laptop quite often and that means closing the lid and moving around.

First of all, mosh is amazing and allows you to stay connected via ssh, even with crappy (airport/hotel) internet as well as moving around networks -- that solves half the problem. If you are not using it, start using it now!

Second, during my datacenter technician days at Google we used to have a "jump server" -- a shell server that allowed us to bridge the corporate network and ssh into prod machines. Doubt that's still used nowadays, but the idea stuck. I wanted something similar to ssh from, wherever I was, and easily connect to my servers. And as the network the shell server is running on is stable, I only need to use mosh to the shell server. Thereafter, the connection very rarely dies.

And I guess, third, I recently purchased an iPad Pro and I really need to have my local "dev" environment with my git repo that I edit quite frequently but iPadOS isn't really your average computer, and doesn't even have a proper terminal. This is my experiment to make iPadOS work as a main computer when on the move.

Enter box -- Docker shell server...

I've copied over the files I use to this example repo, and added some comments. Mind you that this repo acts as a proof of concept and isn't kept up to date, as I have my own private repo -- but this should give you a good idea on how to set up your own shell server with Docker.

start.sh -- this is a simple script that I execute when I first run or need to update the container. I execute the same file on two different servers: Liana, my Raspberry Pi at home and Ocean, my server in Amsterdam.

zsh.sh -- this installs what I care about for zsh. This could be part of the Dockerfile but for some reason I separated it. ¯\_(ツ)_/¯

git.sh -- this clones my Git repos so I can edit and commit stuff from the shell server.

run.sh -- this file is launched by Dockerfile at the end and executes what matters: the ssh daemon. It also adds a Wireguard route and executes the scripts above.

Dockerfile -- this installs everything I need and configures the whole thing. I've added tons of comments that should get you going.

I am also cloning misc and homefiles as submodules in files/ -- but you should change this to something that works for you. See the Dockerfile for more info.

Couple of weeks ago I started to play with NextDNS -- and I really recommend anyone that's something privacy minded and cares about the stuff happening on their network.

I've set up several configs (home, parents, FlatTurtle TurtleBox (the NUCs controlling the screens)) and Servers. Once it's out of beta and better supported on Unifi and Ubiquiti hardware I might deploy it to our public WiFi (well, most access points don't look like that -- but you get the point) networks too.

Looking at the logs was an eye-opener seeing what goes through your network. You can play around and block (or whitelist) certain domains.

I figured out my Devialet does an insane amount of requests to cache.radioline.fr for example. This domain has a 30s TTL. It shows that the majority of my DNS requests are actually automated pings and not in any way human traffic.

Anyhow -- I've since installed the NextDNS CLI straight on my EdgeRouter Lite acting as a caching DNS server and forwarding using DoH.

I've turned off dnsmasq (/etc/default/dnsmasq => DNSMASQ_OPTS="-p0") and have NextDNS listen to :53 directly.

Note that every EdgeOS update seems to wipe out the NextDNS installation, and requires a fresh install... Pain in the ass and doesn't seem like that's fixable.

This is my ERL NextDNS config (/etc/nextdns.conf)

hardened-privacy false
bogus-priv true
log-queries false
cache-size 10MB
cache-max-age 0s
report-client-info true
timeout 5s
listen :53
use-hosts true
setup-router false
auto-activate true
config 34xyz8
detect-captive-portals false
max-ttl 0s

The explanation of every flag is explain on their Github page and they are very responsive via issues or through their chat on my.nextdns.io.

All right -- next thing I've noticed is that my Google Home devices are not sending any DNS requests -- which means the devices use hard coded DNS servers.

I have a separate vlan (eth1.90) for Google Home (includes my Android TV, OSMC, Nest Home Hub and all other GHome and Chromecast devices). For this vlan I set up a deflector to be able to cast and ping/ssh from my "main" network/vlan to GHome vlan.

Using this guide I redirected all external DNS traffic to the ERL so I can monitor what's happening. The important part was the following:

yeri@sg-erl# show service nat rule 4053
destination {
port 53
}
inbound-interface eth1.90
inside-address {
address 10.3.34.1
port 53
}
protocol tcp_udp
type destination

This allows to "catch" all UDP and TCP connections to :53 and redirect them the ERL DNS server (10.3.34.1). The GHome devices were acting a bit weird after committing the change, but a reboot of the device fixed it.

Note that you need to set this up per vlan. If you want to catch DNS requests for your Guest or IoT vlan, you'll need to do the same.

This is mostly stuff that I have found from several articles, mostly from here.

ERL: eth0 is WAN, eth1 (10.60.111.0/24) and eth2 (unused, not VPN’ed) are LAN FritzBoz: 192.168.1.0/24

This is the FritzBox config (go to VPN and them Import a config) fritzvpn.cfg:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "VPN Yeri";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "erl.yeri.be";
                localid {
                        fqdn = "fritz.yeri.be";
                }
                remoteid {
                        fqdn = "erl.yeri.be";
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SOMEPASSWORD";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 10.60.111.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 10.60.111.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

Be sure to modify the password, local (Fritz) and remote (ERL) LAN and edit the local and remote fqdn.

This is the ERL config (via ssh, you’ll need to set this:

yeri@sg-erl# show vpn ipsec 
 auto-update 60
 auto-firewall-nat-exclude enable
 esp-group FOO0 {
     proposal 1 {
         encryption aes256
         hash sha1
     }
 }
 ike-group FOO0 {
     dead-peer-detection {
         action restart
         interval 60
         timeout 60
     }
     lifetime 3600
     proposal 1 {
         dh-group 2
         encryption aes256
         hash sha1
     }
 }
 ipsec-interfaces {
     interface eth0
 }
 nat-networks {
     allowed-network 0.0.0.0/0 {
     }
 }
 nat-traversal enable
 site-to-site {
     peer fritz.yeri.be {
         authentication {
             mode pre-shared-secret
             pre-shared-secret SOMEPASSWORD
         }
         connection-type initiate
         description "VPN to fritz.yeri.be"
         ike-group FOO0
         local-address erl.yeri.be
         tunnel 1 {
             esp-group FOO0
             local {
                 prefix 10.60.111.0/24
             }
             remote {
                 prefix 192.168.1.0/24
             }
         }
     }
 }

Status:

yeri@sg:~$ show vpn ipsec status
IPSec Process Running PID: 20140

1 Active IPsec Tunnels

IPsec Interfaces :
        eth0    (no IP on interface statically configured as local-address for any VPN peer)
yeri@sg:~$ show vpn ipsec sa
peer-be.yeri.be-tunnel-1: #9, ESTABLISHED, IKEv1, 85a2d010ada73113:ca439c40ac3bca06
  local  'erl.yeri.be' @ 116.87.x.y
  remote 'fritz.yeri.be' @ 109.236.x.y
  AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 1592s ago, reauth in 1333s
  peer-fritz.yeri.be-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1024
    installed 1592 ago, rekeying in 1200s, expires in 2009s
    in  c0bb652e, 1038032 bytes, 10726 packets,     0s ago
    out 8d5df3f5, 532685 bytes,  6062 packets,     0s ago
    local  10.60.111.0/24
    remote 192.168.1.0/24

I haven’t really figured out what no IP on interface statically configured as local-address for any VPN peer means yet though.

Next up: VLANs

(Source)

This seems to come with unlimited data for ~20USD for 24hrs. I manage to stream Google Music just fine.

I totally went Matrix mode during the flight. While the flight is half empty I am wondering if they think I am haxoring it now.

EVA uses T-Mobile Germany as carrier.

Public IP routes to a German IP (and Google redirects to Google.de).

nazgul ~ $ curl canhazip.com
88.128.80.215

Whois info:

[...]

inetnum: 88.128.80.0 - 88.128.95.255
netname: ca-de
descr: Telekom Deutschland GmbH
country: DE
admin-c: TH12429-RIPE
tech-c: AS8728-RIPE
tech-c: MS47198-RIPE
remarks: ***************************************************************************
remarks: Please send any abuse complaints to: abuse@telekom.de
remarks: Behoerdenauskuenfte koennen nur ueber folgende Ruf- bzw. Faxnummern beantwortet werden:
remarks: Fax: 0180-18812-66 (0,039 Euro/Minute aus dem Festnetz der Deutschen Telekom AG.)
remarks: Tel.: 0180-18812-77 (0,039 Euro/Minute aus dem Festnetz der Deutschen Telekom AG.)
remarks: ***************************************************************************
status: ASSIGNED PA
mnt-by: MNT-TMD
created: 2008-05-06T07:54:12Z
last-modified: 2012-07-30T08:54:39Z
source: RIPE

Trace routes are quite odd:

nazgul ~ $ traceroute yeri.be
traceroute to yeri.be (83.149.69.152), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 3.429 ms 2.746 ms 2.921 ms
2 10.207.1.1 (10.207.1.1) 2.998 ms 2.535 ms 2.455 ms
3 172.18.15.41 (172.18.15.41) 553.837 ms 536.711 ms 541.207 ms
4 172.18.14.34 (172.18.14.34) 615.658 ms 534.722 ms 536.465 ms
5 * * *
6 yeri.be (83.149.69.152) 728.306 ms 749.172 ms 738.020 ms
7 yeri.be (83.149.69.152) 743.171 ms 735.898 ms 858.885 ms
8 yeri.be (83.149.69.152) 731.611 ms 764.056 ms 734.694 ms
9 yeri.be (83.149.69.152) 745.765 ms 745.182 ms 729.407 ms
10 yeri.be (83.149.69.152) 745.248 ms 1002.078 ms 750.183 ms
11 yeri.be (83.149.69.152) 901.702 ms 758.616 ms 898.359 ms
12 yeri.be (83.149.69.152) 750.162 ms 779.888 ms 863.083 ms
13 yeri.be (83.149.69.152) 777.654 ms 777.442 ms 750.133 ms
14 yeri.be (83.149.69.152) 745.435 ms 783.786 ms 942.607 ms
15 yeri.be (83.149.69.152) 926.653 ms 939.882 ms 830.519 ms
16 yeri.be (83.149.69.152) 1239.295 ms 754.112 ms 753.986 ms

nazgul ~ $ traceroute google.com
traceroute to google.com (172.217.17.46), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 1.716 ms 1.200 ms 2.627 ms
2 10.207.1.1 (10.207.1.1) 2.155 ms 1.932 ms 2.165 ms
3 172.18.15.41 (172.18.15.41) 583.366 ms 588.440 ms 730.303 ms
4 172.18.14.34 (172.18.14.34) 552.347 ms 963.682 ms 550.350 ms
5 172.30.1.34 (172.30.1.34) 841.324 ms * 637.136 ms
6 ams16s29-in-f46.1e100.net (172.217.17.46) 752.359 ms 744.614 ms 819.851 ms
7 ams16s29-in-f46.1e100.net (172.217.17.46) 735.554 ms 737.249 ms 785.678 ms
8 ams16s29-in-f46.1e100.net (172.217.17.46) 766.046 ms 738.774 ms 750.276 ms
9 ams16s29-in-f46.1e100.net (172.217.17.46) 817.491 ms 736.133 ms 765.344 ms
10 ams16s29-in-f46.1e100.net (172.217.17.46) 1047.754 ms 754.939 ms *
11 * ams16s29-in-f46.1e100.net (172.217.17.46) 761.013 ms 762.848 ms
12 * ams16s29-in-f46.1e100.net (172.217.17.46) 840.602 ms 750.186 ms
13 ams16s29-in-f46.1e100.net (172.217.17.46) 935.149 ms 808.133 ms 745.638 ms
14 ams16s29-in-f46.1e100.net (172.217.17.46) 736.075 ms 881.481 ms 788.661 ms
15 * * *
16 ams16s29-in-f46.1e100.net (172.217.17.46) 876.269 ms 1195.194 ms 754.661 ms
17 ams16s29-in-f46.1e100.net (172.217.17.46) 749.985 ms 850.065 ms 742.763 ms
18 ams16s29-in-f46.1e100.net (172.217.17.46) 737.418 ms 1079.194 ms 751.415 ms
19 ams16s29-in-f46.1e100.net (172.217.17.46) 765.339 ms 763.116 ms 754.928 ms
20 ams16s29-in-f46.1e100.net (172.217.17.46) 765.059 ms 767.733 ms 762.777 ms
21 ams16s29-in-f46.1e100.net (172.217.17.46) 860.458 ms 780.965 ms 757.507 ms
22 ams16s29-in-f46.1e100.net (172.217.17.46) 768.432 ms 747.930 ms 764.553 ms
23 ams16s29-in-f46.1e100.net (172.217.17.46) 758.869 ms 747.489 ms 751.329 ms
24 ams16s29-in-f46.1e100.net (172.217.17.46) 797.699 ms 818.899 ms *

nazgul ~ $ traceroute t-mobile.de
traceroute to t-mobile.de (46.29.100.15), 64 hops max, 52 byte packets
1 ns.evawifi.com (172.19.248.1) 1.978 ms 1.080 ms 1.071 ms
2 10.207.1.1 (10.207.1.1) 4.575 ms 1.885 ms 1.847 ms
3 172.18.15.41 (172.18.15.41) 540.670 ms 739.430 ms 787.836 ms
4 172.18.14.34 (172.18.14.34) 646.621 ms 775.771 ms 562.301 ms
5 * 172.30.1.34 (172.30.1.34) 630.660 ms *
6 46.29.100.15 (46.29.100.15) 1014.377 ms 813.739 ms 755.431 ms
7 46.29.100.15 (46.29.100.15) 766.290 ms 805.572 ms 735.697 ms
8 46.29.100.15 (46.29.100.15) 806.918 ms 792.377 ms 945.535 ms
9 46.29.100.15 (46.29.100.15) 783.751 ms 736.085 ms 781.832 ms
10 46.29.100.15 (46.29.100.15) 817.682 ms 738.980 ms 1031.463 ms
11 46.29.100.15 (46.29.100.15) 872.993 ms 767.682 ms 807.777 ms
12 46.29.100.15 (46.29.100.15) 986.659 ms 804.279 ms 806.750 ms
13 46.29.100.15 (46.29.100.15) 846.340 ms 767.556 ms 939.215 ms
14 46.29.100.15 (46.29.100.15) 737.330 ms 759.259 ms 786.724 ms
15 * * *
16 * * *

Not very sure what witchery is going on here.

arp shows AP isolation and two different servers running for the WiFi:

nazgul ~ $ arp -a
ns.evawifi.com (172.19.248.1) at 0:d:2e:0:40:1 on en0 ifscope [ethernet]
www.evawifi.com (172.19.248.2) at 0:d:2e:0:0:a8 on en0 ifscope [ethernet]
? (172.19.249.255) at (incomplete) on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.192.0.0) at 1:0:5e:40:0:0 on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

There seems to be a transparant Squid/3.4.6 caching proxy running:

More random things can be found here.

Email: yeri+sale@tiete.be

Everything has been stored for a while in my garage and is untested.

Dual P3 1u server

• 1u dual Pentium 3 1Ghz server
• 2x 72.8Gb 10k rpm SCSI (one probably died)
• 1280Mb RAM
• Served for years as mail & web server in Amsterdam datacenter, got it myself 2nd hand where it served in a Belgian datacenter (IIRC)
• 2dehands

Intel Pentium D desktop server

• Pentium D CPU (32bit), don't remember any more specs
• Seems to have 4Gb of RAM (untested)
• 2x 160Gb SATA disk
• 2dehands

AMD64 Athlon desktop

• No disks
• Seems to have 1GB of RAM (untested)
• Athlon64 something. You know. One of those first 64 bit CPUs when AMD was still awesome. :)
• 2dehands

APC Smart UPS

• 4u rack mounted UPS
• "SmartUPS 1000"
• With the right cables (not provided) I believe there was a managed console/interface
• Comes with batteries but I'm 99% sure the batteries are dead by now
• it's freaking heavy
• Awesome UPS that proved its use back in the days
• 2dehands

In my case, as the mailserver and webserver are behind a proxy (postfix, imap, Roundcube Webmail), I create the certificate on the proxy (nginx) and scp the cert to the mail server. All this is automated with a tiny script.

For Postfix, edit main.cf and change/edit/add these lines (check the right path too!):

smtpd_use_tls = yes
smtpd_tls_key_file = /etc/ssl/letsencrypt/webmail.privkey.pem
smtpd_tls_cert_file = /etc/ssl/letsencrypt/webmail.fullchain.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_exchange_name = /var/run/prng_exch
tls_random_source = dev:/dev/urandom
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_dh1024_param_file = /etc/ssl/postfix/dhparams.pem
smtpd_tls_auth_only = yes
smtp_tls_security_level = may
smtpd_use_tls=yes
smtpd_tls_security_level=may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_loglevel=1
smtp_tls_loglevel=1

And restart postfix: /etc/init.d/postfix restart

As for Courier you’ll need to concatenate the files (again, check the path, it’s most likely /etc/letsencrypt/live/domain/xyz.pem):

cat /etc/ssl/letsencrypt/webmail.privkey.pem /etc/ssl/letsencrypt/webmail.fullchain.pem > /etc/ssl/letsencrypt/webmail.all.pem

Then edit both /etc/courier/pop3d-ssl and /etc/courier/imapd-ssl

And add/change the path of the certificate:

TLS_CERTFILE=/etc/ssl/letsencrypt/webmail.all.pem

And restart Courier: /etc/init.d/courier-imap-ssl restart && /etc/init.d/courier-pop-ssl restart

Have no fear...

mailq | grep monit@hawk-62e9e0.botnet.corp.flatturtle.com | cut -d' ' -f1 | xargs -rn1 postsuper -d

Edit the e-mail address.

Note: mainly a reminder for myself. ;)

If you're running Postfix, add this line to main.cf:

Restart Postfix, and retry.

PS: You can set encrypt instead of may -- but this can cause issues with Amavis and/or SpamAssassin.

Once again, this is testing the public websites I can access. There might be other gateways, APIs, etc that are not (as) secure.

It’s worthy to note that some banks are serious about security and fixing their SSL. Most improved their rating and solved all issues (especially getting rid of SHA1 in the chain). However, a couple lowered from B to C (see below). But… No more F’s. :)

The noteworthy changers:

• Hello Bank! went from A to B though due to weak DH,
• Triodos lost their Forward Secrecy,
• Optima from F to A(-) (and a bunch others from B to A, and higher),
• A bunch from B to C due to SSLLabs being more severe (see below). Most did solve some of their issues,
• BKCP is doing a lot wrong.

Update 11 Jan 2016: ABK & BvB updated to A.

Note that not supporting TLS 1.2 or supporting RC4 capped sites to grade B about a year ago; it now caps to grade C (aka SSLLabs is more severe).

Grade A

• Rabobank (A+): no known issues.
• Evi (A+): no known issues.
• Crelan (A+): no known issues.
• Binck (A+): no known issues.
• ING (A+): no known issues.
• Keytrade Bank (A+): no known issues.
• CPH (A+): no known issues.
• NIBC Direct (A+): no known issues.
• AXA (A+): no known issues.
• Delta Lloyd Bank (A): no known issues.
• Deutsche Bank (A): weak signature (SHA1).
• MeDirect Bank (A): no known issues.
• Monte Paschi (A): no known issues.
• Belfius (A): no known issues.
• BNP Paribas Fortis (A): no known issues.
• bpost bank (A): no known issues.
• Argenta (A): no known issues.
• Fortuneo (A): invalid HSTS policy.
• Fintro (A): no known issues.
• DHB Bank (A): no known issues.
• VDK (A): no known issues.
• ABK: (A): no known issues.
• Bank Van Breda (A): no known issues.
• Ogone (payment facilitator -- A): no known issues.
• Moneyou (A-): no Forward Secrecy.
• Record Bank (A-): no Forward Secrecy.
• Triodos (A-): no Forward Secrecy.
• Optima Bank (A-): no Forward Secrecy.
• KBC (A-): no Forward Secrecy.
• Isabel (banking tool for corps -- A-): no Forward Secrecy.

• Hello bank!: Weak Diffie-Hell (aka DH) (info).

• PSA Bank: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
• beobank: weak DH, no TLS 1.2, RC4 (insecure), no Forward Secrecy, no secure renegotiation.
• BKCP: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy, weak DH.

• n/a

• n/a

• n/a

(Source)

There is on board WiFi, and it’s unlike those I’ve seen before on Lufthansa.

The WiFi is provided by OnAir (owned by SITA, ex Airbus), a Swiss-Merican company using what cell towers (that’s what their landing page said – but their website says satellites + and it worked over the sea).

I only had a tablet, so very limited information I could dig.

• There is a private SSID active at all times (QTR<plane registration>, in my case it was QTRA7-BCT)
• Once in the air, a new SSID pops up, called "Oryx Comms" (Oryx being Qatar's entertainment system, including personal movie/music displays)
• IP of the gateway is 172.16.64.1
• Blocks all and redirects you to a landing page
• Landing page https://web.archive.org/web/20130802092743/http://onboard.onair.aero -- which seems to be locally hosted in the airplane (it was too fast to be over satellite).
• Price is exuberant
• End user license agreement was dodgy: "personal information logged in Switzerland and/or US of A", "some data retained for quality improvements and better services", "Data not given to third parties, with the exception of XYZ", "both anonymous and personal information used".
• More interestingly: while above a certain height, there was cell coverage inside the plane: "OnAir" network (roaming), allowing you to text and call from the plane.

(Source).

Amazon retails this D-Link for around €120 (including tax). So it’s worth noting it’s almost the same price as a metal, semi outdoor, cloud based camera.

The first things I noticed unpacking:

• Plastic. And it feels very plastic.
• Indoor only.
• The base is a bit light if you just want to set it on a table without screwing it or using glue. The utp and power cable can make it trip easily.
• No PoE (power-over-ethernet).
• Infrared (you can clearly hear the filter 'clicking' when booting up the camera)

This thing comes with ethernet, and, surprisingly, with WiFi. That’ll make it easier to use in small shops. There’s also an option to add a micro SD card as local storage.

While setting up WiFi, I managed to already bug it and lose access by setting up both WiFi and having an ethernet cable connected; and updating the firmware didn’t seem to solve that issue. So it’s basically one or the other. Want to use WiFi? Don’t plug in a cable!

There is a live view (using Java) from the interface: FPS wise it seems quite low, around two-three frames per second, and there is some lag on the interface (setting is set to “max 25 fps” – which apparently is only used when recording).

Quality in a close to dark room is okay-ish – infrared enabled (+ time still wrong on most of the pictures).

Outdoor picture of Antwerp without IR. Not so detailed and CMOS sensor quality is fairly crap.

Indoor pictures during the day (it’s always quite dark in my room – no direct sun).

Close up & view of my kitchen: a bit blurry.

On the other hand – for a D-Link I was surprised with the options from the interface though. You can set up motion (+ select an area to detect motion – not necessarily the whole area) & sound detection, WiFi “just works”, you can generate new self signed or upload your own SSL certificates, access list, QoS, uPnP, DDNS, PPPoE, NTP, IPv6, privacy masking (cover an area), etc.

UX & design isn’t their thing though.

The whole interface, unlike UVC which streams content to a cloud server (and everything is recorded/stored there), is ran from the onboard web interface. There is some separate Windows software you can download – but I have a Mac and it didn’t seem to add much value.

It's still made and translated by Taiwanese people... ;)

All in all, this is a decent camera for small businesses or personal surveillance. It's a bit too expensive, but it does the job and has a decent amount of options.

PS: the default username is admin with no password. Remember to change it, or you’ll have voyeurs looking at you (in case it has a public IP and/or if it automatically opens ports using uPnP) – like I am looking at this man using simple Google queries (I needed examples about for a panel talk at Stibbe about internet security).

PDF can be downloaded here.

Presentation given at Stibbe on 5 May 2015.

# mount -t cifs //192.168.1.100/public -o username=public,password=public sam/ mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

The solution is to add after -o username=X,password=Y the following: sec=ntlm; thus it becomes -o username=X,password=Y,sec=ntlm.

You can do the same in fstab:

//192.168.1.100/public /mnt/sam/ cifs domain=TIETE,username=public,password=public,sec=ntlm 0 0

No idea why it’s suddenly required, but whatevs.

Due to interference (GSM? WiFi (very very unlikely)? High voltage power lines?) we moved it to the side, as seen below.

While it is blind from half a side, it can see all the way up to London and beyond.

This is the result:

As comparison, this is T-EBBR43 (Not placed as high, at my parents’ house):

Merged data from EBBR43, EBBR44 and EBBR55:

I’ll do my usual slashdot-effect post in a couple of days (it’s already at 10k views today).

Banks that changed rank since last post (all for the better):

• 16/02/2015:
  • Keytrade: B to A
  • Hello Bank!: C to A
  • ING: F to A-
  • Record Bank: F to A-
• 17/02/2015:
  • ABK: F to B
  • Bank Van Breda: C to B
• 18/02/2015:
  • MeDirect: F to A
  • Added 6 new (small) banks
• 27/02/2015
  • Ogone: C to A-
• 02/03/2015
  • Fortuneo: C to B
• 03/03/2015
  • Crelan: B to A

I cannot test Europabank using SSL Labs. I can only speculate they requested SSL Labs to not scan them. I have also added a couple new banks (Delta Lloyd, Deutsche Bank, Moneyou, Fortuneo, BKCP, Binck, and Isabel as bank tool).

I would like to apologise for every IT’er that had a crappy Monday morning, and thank you for fixing SSL so fast. :)

The entire list updated (last partial update 18/02/2015 around 20h00):

I’ve updated the sites to now correctly test the login page and not the main homepage. If that’s not the case somewhere, please tell me.

Grade A

• Rabobank (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Triodos (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Evi (A+): no known issues.
• Crelan (A): weak signature (SHA1).
• Delta Lloyd Bank (A): no known issues. [news post]
• Deutsche Bank (A): weak signature (SHA1).
• Hello bank! (A): no known issues.
• Keytrade Bank (A): weak signature (SHA1, intermediate, very very minor issue).
• MeDirect Bank (A): no known issues. [newsletter: 1, 2]
• Monte Paschi (A): no known issues.
• Belfius (A-): weak signature (SHA1), no Forward Secrecy.
• BNP Paribas Fortis (A-): weak signature (SHA1), no Forward Secrecy.
• bpost bank (A-): weak signature (SHA1), no Forward Secrecy.
• Binck (A-): weak signature (SHA1), no Forward Secrecy.
• Fintro (A-): weak signature (SHA1), no Forward Secrecy.
• ING (A-): no Forward Secrecy. [press release via Standaard]
• Moneyou (A-): weak signature (SHA1), no Forward Secrecy.
• Record Bank (A-): no Forward Secrecy. [news post]
• Isabel (banking tool for big corps - A-): weak signature (SHA1), no Forward Secrecy.
• Ogone (payment facilitator): no Forward Secrecy. [newsletter via twitter]

Grade B

• Argenta: SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• ABK: weak signature (SHA1), no TLS 1.2, no Forward Secrecy, no support for secure renegotiation. [update]
• AXA: weak signature (SHA1), SSL3 (insecure), RC4 (insecure), no Forward Secrecy.
• Bank Van Breda: weak signature (SHA1), no TLS 1.2, no Forward Secrecy, no support for secure renegotiation. [update]
• beobank: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• BKCP: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy. [newsletter]
• CPH: no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• DHB Bank: weak signature (SHA1), RC4 (insecure).
• Fortuneo: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
• KBC: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
• NIBC Direct: weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• VDK: SSL3 (insecure),no TLS 1.2, weak signature (SHA1), RC4 (insecure), no Forward Secrecy

Grade C

• PSA Bank: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy.

Grade D

• n/a

Grade E

• n/a

Grade F

• Optima Bank: vulnerable to POODLE attack in SSL3 and TLS format, weak signature (SHA1), RC4, no Forward Secrecy.

Information about SSL Labs grading can be found here. Grade A (+) being the best possible ranking, and F the worst.

Respect to those that send a mailing list to their customers with more detailed information. Communication++

Respect to Rabobank to be the only bank that directly contacted me (officially, not hiding behind a Gmail or Hotmail address) and thanked me for the work I did, asking for more details, etc.

And thank you for an anonymous person, working for one of the big banks, to give me more details about why they are slow at patching this, how legacy works, etc. I wish he could take this discussion public, but alas.

Part three, or how I single-handedly “fixed” SSL at the Belgian banks. ;)

Part one and two are available here. Not related but useful nonetheless NY Times article about bank hackers.

Argenta promised to fix their SSL, so it’s the time to check everything again.

TL;DR: Only Argenta’s status changed for the better.

Those that did not change:

• Rabobank: A+
• Triodos: A+
• Belfius: A-
• BNP Paribas Fortis: A-
• bpost bank: A-
• AXA: B
• beobank: B
• CPH: B
• KBC: B
• Keytrade Bank: B
• Crelan (internet banking): B
• Hello bank!: C
• Bank Van Breda (internet banking): C
  • BvB no longer supports secure renegotiation (which, afaik, it did before). However, it's still rated as C, as this isn't a real issue.
• ING: F
• Record Bank (internet banking): F

Those that did change:

• Argenta (internet banking): F to B
  • No longer vulnerable to POODLE,
  • Support for protocol downgrade attacks prevention,
  • Still using SSL3 (obsolete and insecure),
  • Weak signature (SHA1),
  • RC4 cipher is supported (insecure),
  • No Forward Secrecy.

Still a little way to go for Argenta, but it’s on the right path.

Those that I hadn’t tested before:

• VDK: B
• ABK: F
• MeDirect Bank: F
• Ogone: C (technically not a bank, and promised a fix, but it got delayed).

The entire list updated:

Grade A

• Rabobank (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Triodos (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Belfius (A-): weak signature (SHA1), no Forward Secrecy.
• BNP Paribas Fortis: (A-) weak signature (SHA1), no Forward Secrecy.
• bpost bank: (A-) weak signature (SHA1), no Forward Secrecy.

Grade B

• Argenta: no SSL on main page.
  • internet banking: SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• AXA: weak signature (SHA1), SSL3 (insecure), RC4 (insecure), no Forward Secrecy.
• beobank: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• CPH: no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• KBC: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
• Keytrade Bank: weak signature (SHA1), RC4 (insecure).
• VDK: SSL3 (insecure),no TLS 1.2, weak signature (SHA1), RC4 (insecure), no Forward Secrecy
• Crelan: no SSL on main page.
  • internet banking: weak signature (SHA1), SSL3 (insecure), no TLS 1.2, RC4, no Forward Secrecy.

Grade C

• Hello bank!: vulnerable to POODLE attack, weak signature (SHA1), RC4 (insecure).
• Bank Van Breda: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, weak signature (SHA1), no TLS 1.2, no Forward Secrecy, no support for secure renegotiation.
• Ogone: payment facilitator
  • weak signature (SHA1), RC4, vulnerable to POODLE, no Forward Secrecy

Grade D

• n/a

Grade E

• n/a

Grade F

• ABK: SSL2 (insecure), vulnerable to POODLE attack, weak signature (SHA1), RC4 (insecure), no Forward Secrecy, no TLS 1.2.
• ING: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• MeDirect Bank: vulnerable to POODLE attack, OpenSSL CCS vulnerability (quite bad),
• Record Bank: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, RC4 (insecure), no Forward Secrecy.

Information about SSL Labs grading can be found here. Grade A (+) being the best possible ranking, and F the worst.

Also, shame on you ING. More than any other bank.

Came out very nicely, and it’s quite solid.

3D renders:

Actual printed design:

Opened up unifi:

Design by Seendesign.

More at FlatTurtle’s blog.

Picture enhanced by Google Plus to add dramatic effect. ;)

Original picture here.

I had to restore my trash folder from backups every 7 days (yay for rdiff-backup).

It took me a while to figure it out… The problem first appeared in October, right after several big changes:

• Yosemite update
• Airmail to Airmail 2 update (I was convinced this was the root cause, looking at my clients instead of the server)
• Android 5.0.x
• Android Email app sunset, changes to GMail app
• IPv6 working decently at home after updating my RPi to Fritzbox devices.
• Random connection errors in GMail app (this was due to misconfigured DNS in the GMail app and causing IPv6 catch all to redirect to the webserver instead of the mailserver. It didn't happen consistently because over mobile (4G & lower) there is no IPv6 and at home is randomly falls back to IPv4 as well. IPv4 DNS was well configured.
• Moving my ~100.000 deleted e-mails from "Deleted Items" (OS X Mail default) to "Trash" (Android & Courier default) to stop having to move them manually from one folder to the other every so often. => this was eventually the cause but I didn't realize.

Debugging was also extremely slow as I had to wait 7 days before being able to check if the changes I made helped anything.

I eventually figured out that it was not Airmail when I rebuild my whole mail database and it defaulted back to putting my deleted mails into the Archive folder instead of Trash. Archive mails were kept over 7 days, but items in Trash still removed.

That’s when I started looking at Courier IMAP config: /etc/courier/imapd (and not imapd-ssl).

There’s an option that says:

##NAME: IMAP_EMPTYTRASH:0
#
# The following setting is optional, and causes messages from the given
# folder to be automatically deleted after the given number of days.
# IMAP_EMPTYTRASH is a comma-separated list of folder:days.  The default
# setting, below, purges 7 day old messages from the Trash folder.
# Another useful setting would be:
#  
# IMAP_EMPTYTRASH=Trash:7,Sent:30
#
# This would also delete messages from the Sent folder (presumably copies
# of sent mail) after 30 days.  This is a global setting that is applied to
# every mail account, and is probably useful in a controlled, corporate
# environment.
#
# Important: the purging is controlled by CTIME, not MTIME (the file time
# as shown by ls).  It is perfectly ordinary to see stuff in Trash that's
# a year old.  That's the file modification time, MTIME, that's displayed.
# This is generally when the message was originally delivered to this
# mailbox.  Purging is controlled by a different timestamp, CTIME, which is
# changed when the file is moved to the Trash folder (and at other times too).
#
# You might want to disable this setting in certain situations - it results
# in a stat() of every file in each folder, at login and logout.
#
IMAP_EMPTYTRASH=Trash:7

Comment out that last line, and restart courier-imap(-ssl)… Simple as that.

This solved my issue.

I’m not sure when that config change happened (Debian update?) and I do not know who at Courier thought it was a good idea …. But sheesh.

Going through my Google Analytics I noticed some noteworthy network domains, which Google discribes as “The fully qualified domain names of your visitors’ Internet service providers (ISPs)”.

There are a few more (Belgian) government institutions and universities, and the top in the list are “(not set)” and “unknown”.

Clearly some people at the banks read the post during their work time. So it’s only fair to recheck the websites… Here goes:

Those that I hadn’t tested before:

• CPH: B
• Record Bank (internet banking): F

Those that did not change:

• Rabobank: A+
• Belfius: A-
• AXA: B
• beobank: B
• KBC: B
• Keytrade Bank: B
• Crelan (internet banking): B
• Hello bank!: C
• Bank Van Breda (internet banking): C
• ING: F
• Argenta (internet banking): F

Those that did change:

• Triodos: A to A+
  • downgrade prevention correctly applied.
• BNP Paribas Fortis: F to A-
  • No longer vulnerable to POODLE,
  • Disabled SSL3 (insecure),
  • Disabled RC4 (insecure),
  • Still using a weak signature (SHA1),
  • No Forward Secrecy.
• bpost bank: F to A-
  • No longer vulnerable to POODLE,
  • Disabled SSL3 (insecure),
  • Disabled RC4 (insecure),
  • Still using a weak signature (SHA1),
  • No Forward Secrecy.

Huge thumbs up for these last three banks! Well done, especially BNP & bpost! :)

Keep on shaming the others.

The entire list updated:

Grade A

• Rabobank (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Triodos (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Belfius (A-): weak signature (SHA1), no Forward Secrecy.
• BNP Paribas Fortis: (A-) weak signature (SHA1), no Forward Secrecy.
• bpost bank: (A-) weak signature (SHA1), no Forward Secrecy.

Grade B

• AXA: weak signature (SHA1), SSL3 (insecure), RC4 (insecure), no Forward Secrecy.
• beobank: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• CPH: no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• KBC: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
• Keytrade Bank: weak signature (SHA1), RC4 (insecure).
• Crelan: no SSL on main page.
  • internet banking: weak signature (SHA1), SSL3 (insecure), no TLS 1.2, RC4, no Forward Secrecy.

Grade C

• Hello bank!: vulnerable to POODLE attack, weak signature (SHA1), RC4 (insecure).
• Bank Van Breda: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, weak signature (SHA1), no TLS 1.2, no Forward Secrecy.

Grade D

• n/a

Grade E

• n/a

Grade F

• ING: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• Argenta: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• Record Bank: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, RC4 (insecure), no Forward Secrecy.

Information about SSL Labs grading can be found here. Grade A (+) being the best possible ranking, and F the worst.

Point to Point receiver (Loco M2)

Boxes with power, PoE and switches

Outdoor Access Point (UAP Outdoor+)

The updated cookbooks are on Github.

Changes (commits):

• Better key management
• fr24feed.ini
• No more separate dump1090 launch
• newest fr24 version

Only providing the weak points. Once there is one SHA1 key in the chain, I will report everything as weak.

Check SSL Labs for a full report, including what they actually did good (if anything).

Grade A

• Rabobank (A+): no known issues. Support for HTTP Strict Transport Security and prevented downgrade attacks.
• Triodos (A): no downgrade attack prevention.
• Belfius (A-): weak signature (SHA1), no Forward Secrecy.

Grade B

• AXA: weak signature (SHA1), SSL3 (insecure), RC4 (insecure), no Forward Secrecy.
• beobank: weak signature (SHA1), no TLS 1.2, RC4 (insecure), no Forward Secrecy.
• KBC: weak signature (SHA1), no TLS 1.2, no Forward Secrecy.
• Keytrade Bank: weak signature (SHA1), RC4 (insecure).
• Crelan: no SSL on main page.
  • internet banking: weak signature (SHA1), SSL3 (insecure), no TLS 1.2, RC4, no Forward Secrecy.

Grade C

• Hello bank!: vulnerable to POODLE attack, weak signature (SHA1), RC4 (insecure).
• Bank Van Breda: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, weak signature (SHA1), no TLS 1.2, no Forward Secrecy.

Grade D

• n/a

Grade E

• n/a

Grade F

• BNP Paribas Fortis: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• bpost bank: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• ING: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.
• Argenta: no SSL on main page.
  • internet banking: vulnerable to POODLE attack, SSL3 (insecure), weak signature (SHA1), RC4 (insecure), no Forward Secrecy.

Information about SSL Labs grading can be found here. Grade A (+) being the best possible ranking, and F the worst.

PS: none of the domains support IPv6 (while expected, it would have been nice – Belgium has the highest IPv6 adoption rate for end users, but almost no IPv6 websites or businesses).

However, it’s now time for something new.

As always, as minimalistic as possible.

On a side note, this blog has been moved from vm1 (and one before that) a virtual machine running on a dual Xeon 3070 (2.66Ghz) at Databarn to Akama, a VM on an 8 core Xeon E3-1230 (3.2Ghz) at Leaseweb.

I’ve also correctly repaired IPv6 on this blog. Apparently nginx never and/or stopped correctly listening to IPv6 (suddenly my Android devices displayed errors on this page, Chrome & Firefox on OS X seemed to fall back to IPv4 instantly… Not sure how long it was broken, but it’s back).

Note to self:

listen          yeri.be:443;
server_name     yeri.be;

Does not work with IPv6, it has to be

listen          [::]:443;
server_name     yeri.be;

While I run it on EfikaMX, it should work on most Debian based devices. Just be sure to modify the FR24 software download URL.

This Ansible playbook is untested on its own. It comes out of a way bigger (private) Ansible playbook, and I kind of just copy pasted this part, as others might benefit from it.

After running Ansible, you should reboot for driver blacklisting to work in cases it’s needed on your device (it is on RPis). And be sure to edit /root/flightradar24.sh with your key.

This is the effect, of giving a WiFi hotspot (near a window at traffic lights) two additional SSID; by coincidence the same used by the two biggest local ISPs. You can clearly see when I made the change.

Edit (07/09/2014):

Be sure to have the right hardware: flightradar24.com/dvbt-stick and … obviously … a RPi.

I got a NooElec from Amazon because I didn’t have the patience to wait for something (that might not work) from AliExpress.

As root:

apt-get update && apt-get install cmake gcc pkg-config libusb-1.0 make git-core libc-dev git clone git://git.osmocom.org/rtl-sdr.git cd rtl-sdr mkdir build cd build cmake ../ -DINSTALL_UDEV_RULES=ON make && make install ldconfig cd ../..

And be sure to Blacklist the normal driver:

echo “blacklist dvb_usb_rtl28xxu” > /etc/modprobe.d/dvb-t.conf

And at this point you should reboot.

As regular user (screen part is no longer needed as the new FR24 program will automatically launch and execute it for you):

git clone https://github.com/MalcolmRobb/dump1090.git cd dump1090 make ln -s dump1090 /bin/ screen -dmS dump ./dump1090 –interactive –net –net-beast –net-ro-port 31001 –net-http-port 8888 cd ..

Now get the FR24 software. In case you get a 404, get the latest version here new Raspberry Pi version is here, Linux (AMD64 & ARMv7) is here. You can get your long & lat here. Follow the updated howto on the page. The underlying code is no longer relevant.

wget https://web.archive.org/web/20141002002531/https://dl.dropboxusercontent.com/u/66906/fr24feed_arm-rpi_242.tgz tar xvzf fr24feed* ./fr24feed_arm-rpi_242 –signup

I’ll ask a couple of questions (answer them correctly):

Step 1/5 - Enter Latitude (DD.DDDD) $:50.927358 Step 2/5 - Enter Longitude (DD.DDDD) $:4.399928 Step 3/5 - Enter your email address (username@domain.tld) $:yeri@tiete.be Step 4/5 - Enter your the hostname of the data feed (leave empty for localhost) $: Step 5/5 - Enter your the port number of the data feed (leave empty for 30003) $:

[…].

It will give you a key (and e-mail it to you) after a couple of minutes. Keep this key, as it’s important.

That’s it. As dump1090 is already running, all you have to do is start flightradar and you’re good to go.

This is the script I use to start it all (in screen, allowing me to check it). As normal user:

nano -w flightradar.sh

And copy paste the following (+ edit the variables):

#!/bin/bash KEY=YOUR-KEY-EDIT-THIS DIR=/home/PATH-TO-YOU-SCRIPT

screen -dmS flightradar24 ./fr24feed_arm-rpi_242 –fr24key=$KEY

And run: chmod +x flightradar.sh

To start the script, simply run ./flightradar.sh, and check what’s happening with screen -r dump or screen -r flightradar.

To auto start this script at boot time, I edit rc.local as root:

nano -w /etc/rc.local

And add the following at the end but BEFORE exit 0:

su yeri -c /home/yeri/flightradar.sh

Obviously, modify the path and the user it should run under (in this case as “yeri”).

PS: Be sure to signup again every time you move your Raspberry around (the coords seem to be hardcoded in the key). PPS: You can get Premium access here now: flightradar24.com/premium (and check fancy graphs about your “radar”).

This is the mail system at host rootspirit.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<xxx@gmail.com>: host
gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b] said: 550-5.7.1
[2001:1af8:3100:a00a:21::1010 12] Our system has detected that
550-5.7.1 this message is likely unsolicited mail. To reduce the amount
of spam 550-5.7.1 sent to Gmail, this message has been blocked.
Please visit 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550 5.7.1 more information. df5si15766518wjb.42 - gsmtp (in reply to end of DATA command)

There is no difference if the mail is a one word e-mail or a wall of text that crits over 9000.

The easiest way to bypass this silly check is to set up a rDNS (reverse DNS or PTR) for all your IPv6 addresses on the mail server. If you do not have this set, Google will flag all your mails over IPv6 as spam.

If you run dig -x <IPv6 address> you can find out if it’s set (answer section, after “IN PTR”):

# dig -x 2001:1af8:3100:a00a:21::1010

; < <>> DiG 9.8.4-rpz2+rl005.12-P1 < <>> -x 2001:1af8:3100:a00a:21::1010
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 30041
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;0.1.0.1.0.0.0.0.0.0.0.0.1.2.0.0.a.0.0.a.0.0.1.3.8.f.a.1.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
0.1.0.1.0.0.0.0.0.0.0.0.1.2.0.0.a.0.0.a.0.0.1.3.8.f.a.1.1.0.0.2.ip6.arpa. 21599	IN PTR mail.rootspirit.com.

Here is a work around if you cannot set rDNS. This still allows Google to send mail to you, using IPv6. The downside is that you’ll have to do this for ALL Google Apps domains you send e-mail to. Good luck.

For sale: two TP-Link WA7510N (5Ghz). These devices are about a year old, and served for about 10 months to provide internet from my apartment to a neighbouring building in Antwerp.

Because our office moved (all space got rent), internet is no longer required. Right now, I do not have a use-case for these devices (although, it was pretty cool, and I wish I could keep using them somehow).

For the past 10 months, except for some water in the UTP cable, this has been working perfectly, with a good and stable ping.

While I used them for Point-to-Point WiFi, they can be used in a wide variety of modes, including regular AP, etc. Just remember, they run at 5Ghz.

Invoice is possible.

Price: discussable

Contact: yeri+wifi@tiete.be

Last I checked this is kind of illegal in Belgium, but who cares.

Price: free (pick up Antwerp or Grimbergen)

Contact: yeri+gsm@tiete.be

I’m selling about 100 DWA-160 D-Link USB WiFi adapters (Atheros).

These are compatible with Raspberry Pi and do not require an external power source. And are obviously compatible with Linux (firmware-linux-free).

Some of these adapters are new, others are used. Two different generation mixed (see the WPS button in the picture).

These adapters can be used in Master (Acces Point) mode using hostapd, but certain Macbook Pro’s (Broadcom driver afaik) make the driver/firmware crash; last time I checked (1.5 year ago) this bug was known but not solved (yet).

Price: €5/piece (discount possible on bulk).

Contact: yeri+wifi@tiete.be

Located in Antwerp, can ship.

Invoice is possible if required.

Dmesg: v1 (no button):

[  646.386291] usb 1-1: Product: USB2.0 WLAN
[  646.386423] usb 1-1: Manufacturer: ATHER
[  646.386553] usb 1-1: SerialNumber: 12345
[  646.502214] usb 1-1: reset high-speed USB device number 3 using ehci_hcd
[  646.678337] usb 1-1: firmware: agent loaded carl9170-1.fw into memory
[  646.678659] usb 1-1: driver   API: 1.9.4 2011-08-15 [1-1]
[  646.678836] usb 1-1: firmware API: 1.9.6 2012-07-07
[  646.679032] usb 1-1: driver does not support all firmware features.

v2 (button):

[    4.400971] usb 1-1.3: Product: 11n adapter
[    4.411771] usb 1-1.3: Manufacturer: ATHER
[    4.416202] usb 1-1.3: SerialNumber: 12345
[    5.303410] usb 1-1.3: reset high-speed USB device number 4 using dwc_otg
[    5.487969] usbcore: registered new interface driver carl9170
[    5.504670] usb 1-1.3: driver   API: 1.9.7 2012-12-15 [1-1]
[    5.510264] usb 1-1.3: firmware API: 1.9.6 2012-07-07

mother ~ # dig mother.titify.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mother.titify.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12227
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mother.titify.com. IN A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Sep 28 18:08:19 2013
;; MSG SIZE rcvd: 35

As you can see, there is a QUESTION section, but no ANSWER. This is an example with a CNAME:

airgul ~ $ dig netly.io

; <<>> DiG 9.8.5-P1 <<>> netly.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2513
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;netly.io. IN A

;; ANSWER SECTION:
netly.io. 21600 IN CNAME mother.netly.io.
mother.netly.io. 21600 IN CNAME mother.titify.com.

;; Query time: 277 msec
;; SERVER: 10.60.111.1#53(10.60.111.1)
;; WHEN: Sat Sep 28 20:06:00 CEST 2013
;; MSG SIZE rcvd: 78

Solution:

mother # /etc/init.d/pdns stop
mother # /etc/init.d/pdns monitor

Will probably give an error message such as:

Sep 28 18:08:02 Should not get here (ns1.titify.com|1): 
please run pdnssec rectify-zone titify.com
Sep 28 18:08:02 Should not get here (ns2.titify.com|1): 
please run pdnssec rectify-zone titify.com
Sep 28 18:08:02 Should not get here (ns1.netly.io|1): 
please run pdnssec rectify-zone titify.com
Sep 28 18:08:02 Should not get here (ns2.netly.io|1): 
please run pdnssec rectify-zone titify.com
Sep 28 18:08:10 Should not get here (mother.titify.com|1): 
please run pdnssec rectify-zone titify.com
Sep 28 18:08:19 Should not get here (mother.titify.com|1): 
please run pdnssec rectify-zone titify.com

Execute that command:

pdnssec rectify-zone titify.com

and it’s magically fixed.

_netdev

As it will attempt to start the network mounted sshfs before networking has been started.

The entire line looks like this:

user@host:/some/dir /local/path fuse.sshfs defaults,idmap=user,_netdev  0 0

From the man pages:

_netdev

The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).

And not a single fuck was giving. Not one. Please remain calm and keep on hypnotoad.

If GCHQ was indeed the agency concerned then this investigation is unlikely to go anywhere and the most that can be expected is some sort of diplomatic complaint from Belgium to the UK, its EU and Nato partner.

I’ve two RPi’s acting a router and was already running dnsmasq. I decided to give it a try. Note that this howto can actually be used on any DNS serving Linux server.

First of all, don’t go with the pixelserv as it crashes after a few minutes.

Apache is an option that worked fine. A general hint: if you’re already running Apache or whatever on port 80, just add a 2nd static IP and make Apache listen to that.

For example (/etc/network/interfaces) – be sure it’s in the same subnet:

auto eth0:0
iface eth0:0 inet static
 address 10.100.200.254
 netmask 255.255.255.0
 broadcast 10.100.200.255

10.100.200.254 is the Apache IP that just serves a HTTP 200 (or 204).

Here’s the relevant config part (note the HTTP 204 code, more info on that later):

<VirtualHost adblock:80>
 ServerAdmin webmaster@domain.net
 DocumentRoot /var/www
 <Directory />
 Options FollowSymLinks
 AllowOverride All
 </Directory>
 <Directory /var/www/>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 RewriteEngine on
 RedirectMatch 204 (.*)$
 ErrorDocument 204 " "
 </Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

And edit /etc/hosts to add “adblock”:

10.100.200.254 adblock.local adblock

If I had used the IP instead of adblock I would have had this error:

# apache2ctl configtest
[Mon Sep 16 20:27:21 2013] [error] (EAI 2)Name or service not known: 
Failed to resolve server name for 10.100.200.254 (check DNS) 
-- or specify an explicit ServerName
Syntax OK

With the HTTP 200 code, some browsers expect some content/file in return. So it’s generally safer to use HTTP 204 “No Content”; which basically means “all good but I have nothing to serve you.”

Now, I call myself an nginx fan. Running Apache on a RPi is a no go (at least for me). I could’ve ran nginx on the RPi, but decided to run it on a remote server with an additional IP. At least for now. To preserve resources on the RPi.

Here’s the relevant config to run it on nginx (and be sure this config is the first file nginx parses; or it might redirect all the domains to some other site):

server {
 listen 80;
 server_name pixel.0x04.com 10.100.200.254 _;
 access_log /var/log/nginx/pixel.access.log;
 error_log /var/log/nginx/pixel.error.log;
 expires max;
 autoindex off; 
 rewrite ^(.*)$ /;
 location / {
  return 204 'pixel';
 }
}

And if we test it, this is what we get:

HTTP/1.1 204 No Content
Server: nginx/1.4.0
Date: Mon, 16 Sep 2013 18:36:52 GMT
Connection: close
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000

And that’s it.

<3 nginx

The only downside is that this won’t work with HTTPS. You can run your webbrowser with a self signed certificate, but this will throw errors…

The result:

Unable to complete backup. An error occurred while creating the backup folder.

I have a Raspberry Pi, acting as TimeMachine (using afp/Bonjour/Netatalk).

There are several things I tried to solve this, including messing in the sparebundle from Linux (chowning) and deleting my TM .plist. This probably messed up my backup a bit.

But what seemed to ‘solve’ it for me was:

1. Start a backup manually (it will fail after a minute or two with the above mentioned error)
2. Open finder, and go to the now mounted disk
3. In my case, there was a <date>.inProgress file
4. If TimeMachine mounted the share for you, you will have write access (see notes below)
5. Delete the inProgress file
6. Empty your trash
7. It should be gone:

   

8. Unmount everything
9. Try backing up again

In my case it changed to this error, which happens to me every so often due to corrupt backups (loss of network (because the drive is on VPN, and when I connect to my VPN Mac starts backing up, eventhough I actually don’t really need/want that, it just happens to find the LAN), sleeping at the wrong moment, and Apple just generally not supporting DIY-TimeMachine). So this does mean I have to start from scratch anyhow… :(

Notes: I’ve tried to manually mount the afp or smb share first, and open  the .sparebundle myself via finder.

Like this:

However, both via Finder as via terminal (including sudo) gave permission errors (partly reading, mostly writing) such as:

Picture taking on 23 July 2012 at 02h55 (local time).

Used my Raspberry Pi, with an USB disk as TimeMachine. Another disk as NAS/storage. It’s just quite slow… Not sure whether it’s my WiFi or RPi that can’t keep up.

But for now, it’s working.

2013-02-05 17:44:31 write UDPv4: Can't assign requested address (code=49)
2013-02-05 17:44:33 write UDPv4: Can't assign requested address (code=49)

This seems to appear more often when swapping WiFi/IP range (after my Mac goes into sleep). But also happens when connecting to the same WiFi. It doesn’t change anything whether I disconnect OpenVPN before putting the Mac to sleep.

The solution I’ve found to solve this is:

1. Disconnect OpenVPN (via Tunnelblick)
2. Turn off WiFi
3. Run the script I've attached below (flush.sh)
4. Fill in your admin/sudo password
5. Hit ctrl+C if it doesn't exit instantly (happens in 99% of the cases)
6. Run the script once or twice more to be sure, it will exit correctly this time
7. Reconnect to the WiFi
8. Reconnect OpenVPN (via Tunnelblick): this time it will work

Edit: updated script (29/01/2014)

#!/bin/bash
# Change IFACE to match your WiFi interface 
# (en0 on Macbook Air and Retina, en1 on old Macbook Pros with ethernet) 
IFACE=en0
sudo ifconfig $IFACE down
sudo route flush
sudo ifconfig $IFACE up

In case the script hangs (sometimes, route flush hangs): hit ctrl+C, and execute it again.

Using two of them (and my Guruplug as WiFi AP) I connected my new apartment with my old house (= parents) over VPN.

This way I can access the printers/scanners and NAS at home.

The 2 rPI’s are used as router (using a Macbook Air USB-to-Ethernet adapter as 2nd ethernet (eth1) port). Basic howto’s are easily found using Google to do this (a good starting point).

I made my own installation of Raspbian (as the downloadable image contains too much crap), details here (actually not that easy to find when Googling for bootstrap raspbian etc).

I’ve connected three different LANs over an OpenVPN connection:

• LAN1 (home): 192.168.1.0 (Gateway: 192.168.1.1, VPN ip: 10.9.8.254)
• LAN2 (apartment, ethernet): 10.60.111.0 (Gateway: 10.60.111.1, VPN ip: 10.9.8.250)
• LAN3 (apartment, wifi): 10.10.10.0 (Gateway: 10.10.10.1, VPN ip: 10.9.8.246)

OpenVPN range: 10.9.8.0. The subnet is 255.255.255.0 in all cases.

LAN3 is connected via LAN2 to the internet. So the default gateway of router 10.10.10.1 is 10.60.111.1.

The gateway/routers are all Debian-based Linux systems. I’m using EDPnet as ISP, and thus need to use those Sagem/Belgacom approved routers (BBox-2 hardware). These Sagems are set in bridged mode, and don’t do the PPP stuff. PPPoeconfig on Debian takes care of most of the stuff. As EDPnet provides ipv6, I can ping6 from those routers.

The idea is to connect/ping each and every LAN from any of the clients connected the LANs (without running OpenVPN on the clients; only run it on the gateways).

For example: my PC with ip 10.10.10.15 wants to connect to the NAS with ip 192.168.1.100.

This can easily be achieved by setting a client-config-dir in the openvpn.conf file (or whatever the name of your config):

client-config-dir /etc/openvpn/tiete

And don’t forget to add route pushes:

push "route 192.168.1.0 255.255.255.0"
push "route 10.60.111.0 255.255.255.0"
push "route 10.10.10.0 255.255.255.0"

But here comes the annoying part. As I’m pushing routes 10.60.111.0 via VPN, which is supposed to be my Guruplug’s default gateway as well (ISP > eth0:RaspberryPi:eth1 > eth0:Guruplug, remember?) this was causing quite some routing fuck ups.

The easiest way to solve this was to turn off VPN on the Guruplug all together, and route 10.10.10.0 over the Raspberry Pi, by adding this line to /etc/network/interfaces:

up route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.60.111.2 dev eth1

Then I’ll change the client specific configs on the VPN. Create a file in whatever you picked as client-config-dir, and name it the actual VPN name (the name used when creating the key).

As I have three routers, I created three files (sheeva for my guruplug, Pi for my first rPI and Industry for my 2nd. Yep… Fancy names).

I also want to give a static IP address to the gateways, so I use the option:

ifconfig-push 10.9.8.<valid-ip> 10.9.8.<valid-ip - 1>

And I’ll also add the iroute option to push routes.

This is what it looks like for the router on the 192.168.1.0 network (“Pi”):

ifconfig-push 10.9.8.254 10.9.8.253
iroute 192.168.1.0 255.255.255.0

For “Sheeva”, the WiFi AP on 10.10.10.0:

ifconfig-push 10.9.8.246 10.9.8.245

And for 10.60.111.0 plus 10.10.10.0 routed over 10.60.111.0 (“Industry”):

ifconfig-push 10.9.8.250 10.9.8.249
iroute 10.60.111.0 255.255.255.0
iroute 10.10.10.0 255.255.255.0

And don’t forget to set up masquerading over tun0 (or tun+) with iptables.

Now… Oddly enough, this didn’t require that much configuration, cursing and stress… And, well, it kind of just works.

From my Mac to my NAS:

nazgul ~ $ traceroute 192.168.1.100
traceroute to 192.168.1.100 (192.168.1.100), 64 hops max, 52 byte packets
 1 sheeva (10.10.10.1) 1.936 ms 1.159 ms 0.800 ms
 2 10.60.111.1 (10.60.111.1) 1.456 ms 1.776 ms 1.539 ms
 3 10.9.8.254 (10.9.8.254) 55.745 ms 55.046 ms 54.734 ms
 4 192.168.1.100 (192.168.1.100) 62.302 ms 55.327 ms 54.795 ms

From Pi (gateway 192.168.1.1) to nazgul, my Mac:

pi ~ # traceroute 10.10.10.15
traceroute to 10.10.10.15 (10.10.10.15), 30 hops max, 60 byte packets
 1 10.9.8.250 (10.9.8.250) 65.892 ms 74.177 ms 73.957 ms
 2 10.60.111.2 (10.60.111.2) 73.441 ms 72.902 ms 72.342 ms
 3 10.10.10.15 (10.10.10.15) 71.780 ms 71.187 ms 70.760 ms

From Heartbeat (10.9.8.102), my Munin stats server to the printer:

heartbeat ~/bin # traceroute 192.168.1.90
traceroute to 192.168.1.90 (192.168.1.90), 30 hops max, 60 byte packets
 1 pi (10.9.8.254) 39.835 ms 40.794 ms 41.567 ms
 2 192.168.1.90 (192.168.1.90) 41.541 ms 42.452 ms 43.307 ms

From Heartbeat to Sheeva’s eth0 IP:

heartbeat ~/bin # traceroute 10.60.111.2
traceroute to 10.60.111.2 (10.60.111.2), 30 hops max, 60 byte packets
 1 industry (10.9.8.250) 32.716 ms 32.615 ms 34.359 ms
 2 sheeva (10.60.111.2) 34.405 ms 34.349 ms 35.014 ms

From Heartbeat to an Android device (not sure why the latency spike):

heartbeat ~/bin # traceroute 10.10.10.72
traceroute to 10.10.10.72 (10.10.10.72), 30 hops max, 60 byte packets
 1 industry (10.9.8.250) 31.337 ms 32.269 ms 32.218 ms
 2 sheeva (10.60.111.2) 33.006 ms 33.052 ms 32.996 ms
 3 10.10.10.72 (10.10.10.72) 471.564 ms 472.169 ms 473.082 ms

Next up (once I have spare time): try to sync local DNS and fix local ipv6.

I’ll put most of the configs on Github at some point.

Debian network file (/etc/network/interfaces):

iface eth3 inet manual

auto xenbr0
iface xenbr0 inet static
        bridge_ports eth3
        address 10.19.86.1
        broadcast 10.19.86.255
        netmask 255.255.255.0

NAT is running on eth2, bridging on eth3 (/etc/xen/xend-config.sxp):

(network-script 'network-nat netdev=eth2')

Now, for the VM configs:

NAT:

vif         = [ 'ip=172.16.1.12,mac=00:16:3E:5E:0D:1A' ]

Bridge:

vif         = [ 'ip=85.12.6.178,mac=00:16:3E:1D:F5:6C,script=vif-bridge,bridge=xenbr0' ]

It’s magic and it works! ;)

And not just China, but any country where they tend to censor certain websites.

Greatly appreciated. :)

I only retweeted and posted the image on my blog. @raf__ is the author of this image (or at least, the one that spread it). Not me.

I thought the “Source” part at the end of my blog was clear enough…

De aanhoudende YouTube-problemen bij Telenet inspireerden Twitteraar Yeri Tiete (@Tuinslak) tot deze satirische advertentie.

ZDnet was wrong. Now ITprofessionals. Who’s next?

I had to root it to get OpenVPN, ssh tunnel, or system wide proxies up and running. Things I needed to by-pass the Great Firewall in China on my mobile.

However, when landing in Beijing, and connecting to Twitter, Facebook, and all that other shizzle on my “backup” Nexus S; I noticed all sites were working just fine. Just a tad slow…

I was amazed. As if someone turned off the Great Firewall… ;)

But apparently, when checking what public IP my phone had, it was a Belgian IP address. So basically it seems when roaming, all traffic is rerouted from, say, China Mobile to Proximus (through a VPN?), and routed to the internet, in my case, from Belgium. Which is pretty cool here in China. Means I can access everything as if I were in Belgium.

Anyway, something I didn’t know. Learned something new today. ;)

NTP:

Mar 26 20:31:50 localhost ntpd[1055]: ./../lib/isc/unix/ifiter_ioctl.c:348: unexpected error: Mar 26 20:31:50 localhost ntpd[1055]: making interface scan socket: Permission denied Mar 26 20:35:09 localhost ntpd[1055]: ntpd exiting on signal 15

Regular user:

yeri@gplugD ~ $ ping google.be ping: unknown host google.be yeri@gplugD ~ $ ping 85.12.6.171 socket: Permission denied yeri@gplugD ~ $ ssh localhost socket: Permission denied ssh: connect to host localhost port 22: Permission denied

Root:

gplugD ~ # ping 85.12.6.171 -c 1 PING 85.12.6.171 (85.12.6.171) 56(84) bytes of data. 64 bytes from 85.12.6.171: icmp_req=1 ttl=58 time=37.1 ms — 85.12.6.171 ping statistics — 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 37.145/37.145/37.145/0.000 ms

Solution? It’s an issue (well, not really an issue, more working like intended) of this kernel flag

CONFIG_ANDROID_PARANOID_NETWORK

And you can fix it by adding the aid_inet group – and adding your user(s) too it. Don’t forget to add NTP etc as well.

gplugD ~ # groupadd -g 3003 aid_inet gplugD ~ # usermod -G -a aid_inet $YOUR-USER

Special thanks to Tim Besard!

(My Serverfault link)

Edit, from the Serverfault page:

On Android Jelly Bean (4.1) used on the Nexus 7, I had to use the group name inet instead of aid_inet, thus:

$ groupadd -g 3004 inet

I used 3004 instead of 3003 because 3003 was already taken by aid_inet

$ usermod -G inet <username> Some code snippets from the Android Kernel related to this go here: http://blog.appuarium.com/2011/06/23/how-android-enforces-android-permission-internet/

Github repo riiiiiiight here. It’s used by my PAC-generator.

The Github page is updated once a day by three hosts. One in Belgium, one in The Netherlands, and a Guruplug in China. This way you can compare the results (in case some are down or replying slowly).

As it’s impossible to test every possible site, I just check popular sites (and a bunch of sites from Alexa). But if you know blocked sites not in the list, please submit them – thanks!

At the moment I recheck every site once a day. However I might change this to once/week or something if the list of sites/URLs gets too big.

More shells are welcome, especially in countries such as Libya, Egypt, Tunis, etc ;)

But also additional shells in China are welcome, to prevent the government from blocking my current machine. All I need is a bit of CPU power once/day, 100Mb quota (at most), and Git installed.

Test results are written to three files; a file with sites that work, a file with sites that didn’t get a HTTP 200 reply, and a file with both. You can directly use the file in your application from Github (for example the list of blocked sites in China).

The files are written as CSV-file; "url,check-date,check-time,{ok|nok}". Ok means the url/site got downloaded, nok means something went wrong (connection reset, time out, etc).

It does NOT check the content of the website (in case a ISP redirects to a different website instead).

This is work in progress though. So it's likely to change and, hopefully, improve in the future.

Feedback is also greatly appreciated.

The PAC file generated redirects all matching rules through the proxy.

The only issue at the moment, is that, once the list gets big, it’s not very performance-friendly. Something I’ll try to fix in the coming days.

I’m using this script to generate a proxy.pac file at work to redirect blocked content in China through the proxy for our employees currently in China.

You can find the Github repo here. Keep in mind it’s work in progress.

SSL is clearly the new hype, and this time I won’t be last to join it! ;)

Just going to check how much (if any) SSL slows down my site.

Every http requests gets automatically rewritten to https.

So, here it is. Download this file and put it in /usr/share/squid/mib.txt.

I don’t quite remember where I found that mib file. Probably included with Squid on Gentoo or the world wide web… But I couldn’t find it on Debian, so here it is. And be sure to add these lines to your Squid config:

acl snmppublic snmp_community public
snmp_port 3401
snmp_access allow snmppublic all

This is what it should look like (low usage Squid):

A while back, I found a quick fix for this; rename the interface targets from their respective ID to their name:

Target[eth0]: 2:public@localhost

becomes

Target[eth0]: #eth0:public@localhost

#
# Eth0 stats
#
Options[eth0]: growright, nobanner, pngdate, nopercent, noinfo
Target[eth0]: #eth0:public@localhost:
SetEnv[eth0]: MRTG_INT_DESCR="eth0"
MaxBytes[eth0]: 1250000
Title[eth0]: Traffic Analysis for deng
PageTop[eth0]: <H1>Traffic Analysis for deng (eth0)</H1>
#
# Eth1 stats
#
Options[eth1]: growright, nobanner, pngdate, nopercent, noinfo
Target[eth1]: #eth1:public@localhost:
SetEnv[eth1]: MRTG_INT_DESCR="eth1"
MaxBytes[eth1]: 1250000
Title[eth1]: Traffic Analysis for deng
PageTop[eth1]: <H1>Traffic Analysis for deng (eth1)</H1>
#
# tun0 stats
#
Options[tun0]: growright, nobanner, pngdate, nopercent, noinfo
Target[tun0]: #tun0:public@localhost:
SetEnv[tun0]: MRTG_INT_DESCR="tun0"
MaxBytes[tun0]: 1250000
Title[tun0]: Traffic Analysis for deng
PageTop[tun0]: <H1>Traffic Analysis for deng (tun0)</H1>

Kinda thought it might be too simplistic (I’ve hidden the sidebar, there’s no search or archive, etc), but I started to, you know, get attached to it.

So it’s here to stay, for a year or something. I guess.

I’ve also noticed that the long load times on my blog were WP_Buzz’s fault. Nice plugin, but 15 to 45 seconds of load time per uncached page wasn’t really worth it. Hope it can be fixed.

I’ve always thought it was One that wasn’t keeping up with the SQL queries, and as refreshing the page always fixed my problem, I thought it just was bad luck and/or my dodgy connection. Until I saw WordPress was doing half a minute for about 90ish SQL queries… Per page.

But on the other hand, seems like changing from One to vm1 was useful after all:

Anyway, to search on this blog use Google or, if you have Chrome, type in blog.tuinslak<tab> and add your search query. Kinda rocks feature!

Been on posting spree lately. Not all post quite as useful, but hey. Let’s see how long I keep up! ;)

And pretty happy I set up my nginx caching up a few weeks ago.

MRTG traffic stats on vm1, my nginx caching server, of the first 2 days (only major traffic source is this blog):

Top referrers (though not 100% accurate):

Website hits:

Top posts last few days:

Flickr hits last few days:

Screenshots are all a few days old by the way.

This, and a bunch of other cool stats from Google Analytics. :)

Oh, and also, visits on iRail.be from the NMBS/SNCB network starting Sept 1 2008:

Here are some stats: image+html and php. Note that the php on apache (recompiled each request, about 1.5-2sec between every request) versus the cached output has a huge difference. Difference between images and static text files aren’t that huge. Also note that nginx has gzip enabled. The downside is that nginx caches all pages (HTTP code 200) for one hour and isn’t notified when pages are modified (yet).

My “live” blog is also accessible using blog.yeri.be as blog.tuinslak.org will now point to the nginx reverse proxy.

I’ve come across a few issues though, pages such as this (shows your current IP address) and this (compare to this and refresh a few times) are cached as well, and actually show the previous visitor (if any) their output and the pages aren’t updated when a new visitor visits them. Edit: fixed, correctly refreshes; .php under wp- isn’t cached.

Same goes for layout (I use WPtouch for mobile devices). A page that got visited on the iPhone and then on a desktop as well as a page that got first cached using a desktop browser and then an iPhone. I’ve disabled WPtouch for now.

And a 3rd issue is that the Wordpress stats image () is cached as well. So if a regular visitor visits the site before a a registered user (admin), the stats image will still be present (and generate incorrect stats). This doesn’t happen the other way around, as no pages are cached for a registered user (unless they are already in its cache)… Weird. Edit: fixed by watching the http cookie and this plugin. Admin pages are never cached now but at least stats are correct again.

Speed gain is insane though.

vs

cache.blog.tuinslak.org 85.12.6.171 - - [22/May/2010:16:27:40 +0200] “GET /2010/05/nginx-reverse-proxy/ HTTP/1.0” 200 22639 “-” “Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.53 Safari/533.4” 1771 23031

First one being my current home IP address, the second one being the nginx server IP address. The idea is to have the first line to show up in the logs.

On Gentoo (and I guess it’s fairly similar on other distributions);

*  www-apache/mod_rpaf
      Latest version available: 0.6
      Latest version installed: 0.6
      Size of files: 7 kB
      Homepage:      http://stderr.net/apache/rpaf/
      Description:   Reverse proxy add forward module
      License:       Apache-2.0

Emerge it, add “-D RPAF” to /etc/conf.d/apache2 and add the following the the correct vhost (e.g. /etc/apache2/vhosts.d/your_vhost.conf):

<IfModule mod_rpaf.c>
      RPAFenable On
      RPAFsethostname On
      RPAFproxy_ips 85.12.6.171
</IfModule>

Change the bold IP address to your nginx rproxy IP address

Might be safe to run “apache2ctl configtest” to make sure you don’t have any errors in your config file(s).

And restart Apache. This makes it show the correct IP address in its log files.

Next on my to do list, getting it to actually cache something.

I’m deliberately making a difference between cache.* and live.* as blog.tuinslak.* might move to the cached version lateron.

The question, is it useful to reverse proxy this blog? No, probably not. But meh… It’s fun. :)

IP differences between both versions: live vs cache°. I’m guessing as most of the stats (Google Analytics and WP Stats) are JavaScript based, all stats should still be correctly generated. Only the Apache logs show the nginx proxy IP address. Which is normal, I guess.

First small test doesn’t seem too good. Apparently not a lot of caching is going on. Though most of this site’s content is HTML (using WPSuperCache).

• Live, on One, using Apache: here & here
• Proxy, on VM1, using nginx: here & here

More tests & fine tuning later!

(°): Due to a minor edit, the live and cached version both show the correct IP address (yours) instead of the nginx proxy IP address.

As I need to run OpenVPN using the TCP protocol (instead of the faster UDP protocol; as UDP is often blocked in networks I use my VPN in) I experimented by increasing the tcp-queue-limit. The default is 64, and I’ve set it to 256. So far, everything still seems to be working fine (but more packets will be queued before being dropped by OpenVPN, requiring less retransmissions).

Add this to the OpenVPN server config:

Any feedback or comments about it can be mailed (yeri @ rootspirit . com) or left below.

Running Wireshark I found that only about 5ish packets got transferred, and all other data to that website abruptly stopped.

I’m using ADSL (EDPnet), which has an MTU of 1492, however, I was able to access all websites from the router (using lynx, for example), but not from any other PC within the network.

# ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
inet addr:85.234.196.57  P-t-P:85.234.196.1  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492 Metric:1
RX packets:38804442 errors:0 dropped:0 overruns:0 frame:0
TX packets:28930886 errors:0 dropped:5020 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:45941523311 (42.7 GiB)  TX bytes:2887926670 (2.6 GiB)

Thinking it might have been a firewall issue, I flushed all my iptables rules, and started over from scratch. However, this too didn’t solve my issue.

When I VPN’ed or used my Macbook Pro directly as PPPoE device (by-passing the Gentoo router) I was able to access all the websites as well.

After being close to giving up, I found the following iptables rule:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -t mangle

And try again.

This did solve my issue. :)

This is because the default 100mbit MTU is 1500, instead of 1492 for PPPoE.

Anyway, been testing it since this summer, and so far it’s been working great.

the DNS server running on a Debian virtual machine, hosted by Rootspirit, near Amsterdam.

IP address: 85.12.6.171

Hostname: vm1.rootspirit.com

Might not be an easy to remember IP address (unlike 4.2.2.1), but as I use that IP pretty much every day, it’s okay for me. ;)

Edit: Let me remind you that I do not agree with NX domain hijacking, or falsifying/redirecting certain DNS requests (such as OpenDNS google.com to google.navigation.opendns.com or the Belgian ban on stopkinderporno.com and redirecting it to 84.199.40.99).

Check out this awesome tool to find the best DNS servers near you.

However, this GUI includes an old OpenVPN, that is no longer compatible with Windows 7 and Windows Vista.

The TUN/TAP driver will be blocked due to compatibility issues, and when trying to connect to a VPN, you’ll get an error along the lines of:

All TAP-Win32 adapters on this system are currently in use

The simplest fix, is to install the GUI package (including the old OpenVPN binaries), and reinstall OpenVPN afterwards.

You can find the latest OpenVPN binaries here and the latest version, when writing this post here.

This will overwrite the old files and update the driver with a Windows 7 compatible driver.

Try to connect now, everything should work like a charm. :)

Here are some examples:

Zero - One - Four - vm1 - Sauron

The config files:

Sauron (including Squid stats),

Zero (including fan stats).

List of files included:

• indexmaker; simple script (included with MRTG) to generate a simple index file with all the graphs
• snmp-if.sh; will show you the IDs of the interfaces on the server/pc. These IDs have to be edited in the mrtg.cfg file; e.g.:

Target[eth0]: 2:public@localhost:

Make sure 2 is indeed the ID of eth0. Be aware that virtual interfaces, like the TUN/TAP interfaces (using by openVPN for example), can change ID each time they are restarted/rebooted.

• mrtg.cfg; check the config file as an example.

Some day, I’ll write a decent howto, but for now, you’ll have to do with this.

If there’s any question, just leave a comment.

To enable tethering on the iPhone + Windows; just pair the bluetooth devices (I actually haven’t tried with USB yet, and don’t really plan on doing that), Windows will start to QQ about it being unable to find a suitable driver for the iPhone… I even installed iTunes to see if the message would go away, but apparently it won’t. I’ll have to do some more Googling later on.

Anyway, to tether, just go to “Control Panel” > “View devices and printers” (under “Hardware and Sound”) > Devices > $iPhone_Name (it has a fancy yellow warning sign next to it…).

Right click, “Connect using” > “Access point”.

Simple enough. Pick “Public network”, just to be sure (though, your ISP should already block most direct connections between devices, and your iPhone won’t forward any ports I guess/hope).

And don’t forget to disable WiFi or unplug your network cable if you want to test it at home.

Oh, right, and I probably should give you a bunch of warnings about data consumption and that AT&T might brutally murder you and your family if you dare using tethering (as far as they can actually check you’re tethering, and if they can, I’m pretty sure they’ll be violating a couple of privacy laws). As for the customers of the 95% other decent providers who allow tethering and aren’t living in the middle ages, have fun using it. Finally work can be done on the train/while waiting/… ;)

#!/bin/bash
KEY=YourApiKey
HOST=zero.rootspirit.com
ping -c 1 $HOST   &>/dev/null
if [ $? -ne 0 ] ; then
curl -k -s "https://prowl.weks.net/publicapi/add?apikey=$KEY&application=Server%20Connectivity%20Failure&event=&description=$HOST&priority=2"
fi

Of course, change KEY to your API key, HOST to the IP or DNS of the server it should ping. Also, make sure, that when pinging on your host where you’ll run the bash script on, a non-existing domain actually returns:

ping: unknown host ezfzigjagaqg.reg

instead of

PING ezfzigjagaqg.reg.rootspirit.com (85.12.6.130) 56(84) bytes of data.

(Should depend on the search line in /etc/resolv.conf) As I’m pinging about 6 servers I created the file “checkServers.sh” with this content:

#!/bin/bash

`/home/yeri/prowl/zero.rootspirit.com.sh &>/dev/null`
`/home/yeri/prowl/one.rootspirit.com.sh &>/dev/null`
`/home/yeri/prowl/two.rootspirit.com.sh &>/dev/null`
`/home/yeri/prowl/four.rootspirit.com.sh &>/dev/null`
`/home/yeri/prowl/vm0.rootspirit.com.sh &>/dev/null`
`/home/yeri/prowl/vm1.rootspirit.com.sh &>/dev/null`

Make sure to chmod +x *.sh, to make it executable, and edit crontab and add something like that:

*/10	*	*	*	*	/home/yeri/prowl/checkServers.sh &>/dev/null

Don’t forget to test it whether it works or not (try non-existing domain(s), and run the script again).

This resulted in a constant error; “The pin code was not accepted by the mobile device”.

I of course removed the SIM card each time, and inserted it back in my iPhone, and unlocked it by inserting my code. I didn’t want to lock my SIM card, and made sure I had at least 2 good tries left each time.

As you can let the application remember the pin code, I was 100% sure it were wrong settings. The worst part, was that the application quits after prompting  that message. I reinstalled, searching in the config files, removed all vodafone files, tried in Windows, changed my pin code a couple of times (the default 0000 one too), updated the HAUWEI firmware, updated the Mobile Connect client software, rebooted, and when I was about to give up, it hit me like a truck. I’m from the bloody “hotswap generation”. And Vodafone sucks. Seriously. Wasted 2 hours on that. Such a waste of time, such a simple solution.

When inserting the SIM card into the device. UNPLUG THE USB MODEM. INSERT SIM. THEN, NOT BEFORE, INSERT IT IN THE DAMN PC. Start the application. Enjoy. No more dodgy error messages, the application works, and you can connect to the bloody internet.

GG Vodafone. GG hotswap.

I'm using Mac OS X (Leopard) as client, and a Gentoo server as server/host.

I both tried Viscosity and Tunnelblick on my Mac as OpenVPN software, and Viscosity is probably somewhat easier to configure (using the GUI), it was shareware. So I ended up using Tunnelblick and it seems to be doing its job quite well.

First of all, make sure Gentoo is set up and working as intended. I used my home router as VPN server (having both eth0 and eth1 (= ppp0).

Using this howto, you'll be able to get the server up and running.

Besides the installation, and perhaps (config) file locations it should be pretty similar on other Linux distros.

As I have dnsmasq running on my server (taking care of DNS) I added the following to the server.conf:

push "dhcp-option DNS 10.0.0.1"
push "redirect-gateway def1"
client-config-dir ccd
route 10.20.30.0 255.255.255.252

Don’t forget to allow DNS requests over tun0 interface in dnsmasq.conf.

The first line tells the server to hand out 10.0.0.1 as DNS server to its connecting clients (10.0.0.1 being the internal eth0 IP of my server).

The 2nd line, tells all clients to route ALL of their traffic through the VPN. I used the VPN to access a website that allowed only Belgian IPs, and I was in The Netherlands at the time I had to access the site (Skynet’s Rock Werchter stream). So I connected through my server at home.

And the 3rd and 4th line are needed if the client access the VPN is on a private IP subnet (like being connected on a WiFi router, using IP 192.168.178.x).

You’ll have to add, in the client-config directory a file per username connecting to the VPN with something similar to this:

iroute 192.168.178.0 255.255.255.0

I’m not entirely sure if you can add multiple iroutes; something I’ll have to figure out when being on a different network.

This is what my client config looks like (vpn-server-name.conf, located in ~/Library/openvpn/):

client
dev tun
proto udp
remote home.tiete.be 9000
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1200
persist-key
persist-tun
ca "ca.crt"
cert "yeri.crt"
key "yeri.key"
tls-auth "ta.key" 1
comp-lzo
verb 3

Yeri being my username. Don’t forget to download and add the ca.crt, user.crt, user.key (located in /usr/share/openvpn/easy-rsa/keys/) and ta.key (located in /etc/openvpn/) you’ve created on the server.

If your client asks for “directions”, pick 1.

Start up server and client software.

Hitting connect in Tunnelblick should connect you to the VPN server, and (in my case) giving me an IP similar to 10.20.30.6. You can check this using “ifconfig” in Terminal.

Client:

tun0: flags=8851 mtu 1500
    inet 10.20.30.6 --> 10.20.30.5 netmask 0xffffffff
    open (pid 20551)

Server:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.20.30.1  P-t-P:10.20.30.2  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
RX packets:407595 errors:0 dropped:0 overruns:0 frame:0
TX packets:574351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:27473209 (26.2 MiB)  TX bytes:603524377 (575.5 MiB)

Don’t forget; when using “tun” as driver, your gateway/VPN server will always have the IP ending on .1 (e.g.: 10.20.30.1).

Now, if you want to route all traffic throug the VPN, like I did, you’ll have to change some stuff in iptables (as the server is also acting as my home router, I already did have a few rules in it).

Allow all traffic through tun0 interface:

iptables -A OUTPUT -o tun0 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT

Allow traffic through the external port 9000 (UDP):

iptables -A INPUT -i ppp0 -p udp -m udp --dport 9000 -j ACCEPT

Enable forwarding and NAT:

iptables -A FORWARD -s 10.20.30.0/24 -i tun0 -j ACCEPT
iptables -A FORWARD -d 10.20.30.0/24 -i ppp0 -j ACCEPT
iptables -A POSTROUTING -o ppp0 -j MASQUERADE

And lastly, as I have Squid running on my server, I want to transparently forward all port 80 requests to the Squid server running on port 8080:

iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

That’s about it. You should have a running VPN from your current location to your VPN server. And you’re able to use it as a gateway.

You can always traceroute/tracepath to your VPN server (10.20.30.1). It should only find one hop.

Since today I ended up getting this error:

Warning: imap_open(): Couldn't open stream {imap.gmail.com:993/imap/ssl}[Google Mail]/Spam in /home/yeri/.gmail.php on line 30
Certificate failure for imap.gmail.com: unable to get local issuer certificate: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com - Connection failed.

Simply searching this line:

$open = imap_open ("{imap.gmail.com:993/imap/ssl/}$path"

And editing it to:

$open = imap_open ("{imap.gmail.com:993/imap/ssl/novalidate-cert}$path"

Solves the problem.

This will ignore the Google certificate. Please do double check that imap.google.com really points to Google, and it’s not some kind of DNS issue.

I’ve updated the 1st version, that ignores the certificate.

When receiving spam in Gmail, you get the annoying bold Spam (12353434) with ‘12353434’ being the number of unread spam messages.

With the introduction of Gmail Labs I’d hope to see an “automaticly mark spam message as seen” feature, which, well, I haven’t found yet.

Being tired of all these increasing spam numbers, and my daily efforts to “select all unread + mark as read”, I ended up writing a small PHP file which connects to the Gmail (using IMAP, so I asume you’ll need IMAP enabled in your settings..) and marks all spam messages as read. Running this script locally with a curl or cron every X time will solve most of your problems, I hope.

Download the file here (phps) or here (txt).

Or just copy paste it!

< ?php
/*
Gmail "spam mark-as-read"

by Tuinslak
www.tuinslak.be

v0.01 :: 26/08/2008 . init php codez
*/

// Config starts here

// Gmail user & pass
$user = "YOU";
$pass = "hiddensecretz";

// Debugging - Outputs a list of mailboxes and status on the imap server (1/0)
$listmailbox = 0;

// Advanced config :o

// "Path" of the (spam) mailbox and/or its name.
// default should be ok with Gmail.
$path = "[Google Mail]/Spam";

// End of config

$open = imap_open ("{imap.gmail.com:993/imap/ssl}$path", $user, $pass, "", 1) or die(imap_last_error() . "

Connection failed.");

// debug
if($listmailbox) {
        echo "<strong>Mailboxes:";
        $folders = imap_listmailbox($open,  "{  Gmail  }", "*");

        if ($folders == false) {
                echo "Call failed\n";
        } else {
                foreach ($folders as $val) {
                        echo $val . "\n";
                }
        }

        echo "</strong><strong>Status</strong>:";
        $status = imap_status($open, "{imap.gmail.com}$path", SA_ALL);
        if ($status) {
                echo "Messages:   " . $status->messages    . "\n";
                echo "Recent:     " . $status->recent      . "\n";
                echo "Unseen:     " . $status->unseen      . "\n";
                echo "UIDnext:    " . $status->uidnext     . "\n";
                echo "UIDvalidity:" . $status->uidvalidity . "\n";
        } else {
                echo "imap_status failed: " . imap_last_error() . "\n";
        }
}

// Mark as read
$search = imap_search($open, 'UNSEEN');
// print out the array containing $search info
//print_r($search);

for ($i = 0; $i < sizeof($search); $i++) {
        $read = imap_setflag_full($open, $search[$i], '\\Seen');
}

// and close it down !
imap_close($open);

// EOF
?>

If you plan to execute it from shell, don’t forget to add a shebang “#!/usr/bin/php” on line 1 and chmod +x gmail_spamreader.php.

Edit: Please add a comment if you’re using it, just for statistics. :)

Been testing it, and seems to be working fine! It’s rather fast (it has a SATA2 disk in it) and it was really easy to set up.

But I’m missing a few things;

• Impossible to format/check the disk for errors from the web interface
• Impossible to create partitions from the web interface
• Impossible to give anonymous FTP access (or use different username:password for FTP, as I don't need any passwords on my disk)
• Only FAT32 (read/write) support, and only NTFS (read) support
• Deleting files seems very slow, but perhaps it's my Mac/WiFi that's giving troubles?

I’m emptying my other (old) external disk (160GB), and will add that one to the network disk (you can extend the network disk by adding other USB disks).

Guess it’s wait-and-see.

Hope the disk won’t crash after 6 months…

All I need now are a few people to come by and test it; I wonder what the range is like.

The only thing I don’t really like is the “Watch our ad and get 15 mins free inet (daily)”. Ad? Watch? Oh come on… Where is this going?!

Nazgul:hamachi-0.9.9.9-20-osx yeri$ ./hamachi start
25 19:08:15.659 [   0] [14306] tap: connect() failed 2 (No such file or directory)

So I guess I’ll have to wait for a fix after all. :(

Here’s a list with all mayor Dutch & Belgian ISPs their SMTP-servers.

Skynet - relay.skynet.be Telenet - uit.telenet.be

Het Net - mailhost.hetnet.nl Home - mail.home.nl KPN - mail.direct-adsl.nl Versatel - relay.versatel.net Xs4all - smtp.xs4all.nl

Ordered it last Saturday (09/02), took just over a week to be delivered (by UPS).

I bought “La Fonera” with a “Fontenna” for just over 6 (!) EUR. Fon’s having this cool promotion that La Fonera only costs around 4 EUR, and if you order a Fontenna with it, you get the Fontenna for just an additional 2 EUR. (And 6 EUR shipping costs. So just over 12 EUR total.)

La Fonera is really easy to configure, perhaps a bit too easy. I hoped a few extra options to configure, and better IP/Bandwidth usage stats, … But on the other side, they managed to keep it simple & clean; easy to use for everyone.

La Fonera has 2 WiFi networks, one public (FON_Tuinslak in my case) and a private one (with WEP, WPA(2); using IP 192.168.10.1 by default)

Notice how small they made it (+-10 x 7,5 cm).

This is the Fontenna, which adds about 7dBi:

Besides having a big gray plastic encapsulation, it seems quite “weather-resistant”. I might put it outside somewhere.

Anyway, it seems to be working great.

I’ll have to play a bit with it, before giving it a final place somewhere in the house… And I’m starting to wonder what I should to with my Linksys “AP”… 2 private networks? Might put it some place where the WiFi signal is really bad… Like… The garage or something. ;)

PS: for those wondering, yes I’ve become a “Bill”. I see no point becoming a “Linus”, because a Bill gets everything a Linus gets plus some extra cash (although I doubt anyone will actually use my Fon AP; I’m kind of living in the middle of nowhere).

$date com.apple.launchd[1] (tuncfgd$pid) posix_spawnp("/usr/sbin/tuncfg", ...):
No such file or directory
$date com.apple.launchd[1] (tuncfgd$pid) Exited with exit code: 1
$date com.apple.launchd[1] (tuncfgd) Throttling respawn: Will start in 10 seconds

tun is (trying) to restart every 10 (!) seconds. I tried updating Hamachi’s tun/tap drivers, without any success. It kept restarting the process every 10 seconds.

After a bit of Googling, it seemed to be a known problem. So I decided to uninstall Hamachi & the tun/tap drivers.

sudo rm -r /usr/bin/hamachi
sudo rm -r  /usr/bin/hamachi-init
sudo rm -r  /usr/sbin/tuncfg
sudo launchctl unload /System/Library/LaunchDaemons/tuncfgd.plist
sudo rm -r /System/Library/LaunchDaemons/tuncfgd.plist
sudo rm -r /Applications/HamachiX

This should solve the restarting problem. You might want to reboot to be sure.

When uninstalling the drivers, HamachiX will be gone; there will be no way to use it. You can decide to ignore the spawning-processes, and keep using Hamachi as-is, but the spawning processes might slow down your computer. But HamachiX should work (although it often crashed here).

I tried reinstalling the tun/tap drivers, but the same happens. I guess I’ll have to wait for a fix. :(

On the other side, I’ve tried the console version of Hamachi (so no HamachiX) which seems to be working fine (so far). Just missing out on the handy GUI. Edit