Apr 302016
My Lifx Bulbs - Resurrected

Some time ago (2013? 2014?) I ordered 2 Lifx bulbs: WiFi connected LED lamps did sound awesome to have. The software resp. firmware was unfortunately flakey (connecting to WiFi took many tries, and occasionally it stopped responding to WiFi). There was also no official API. In the end, it was a pair of unreliable lamps. They worked fine as “dump lamps” though. Last year I tried again, and the software and firmware improve, but I had no lamp that could handle the weight (about 300g).

However, I checked last week and the software improved: new firmware 2.0 available. And plenty APIs documented and plenty connectivity to cloud services. Worth to have another look at those Lifx bulbs.

So I bought a nice clamp light which has no issue with the weight (and a very strong clamp).

The Android app (version 3.5) works. Connecting to the bulk was still a hit-and-miss, but after 3 tries all worked. New firmware is now on both bulbs with the promise that further firmware updates won’t take 30min… we’ll see.

The more fun part is programming the bulbs to do things like “Wake me up in the morning”. I took this as a challende to program in node.js as I imagined a command (for Linux of course) would be too easy (cron+command=done).

There a neat lifx library for node.js available here which was a very good start. Took several attempts to understand how it works, but once it made ‘click’, it was straightforward. And reliable too. Kudos to Marius for the nice library. My result is here and while small, I’m happy about the result.

And because it’s running on node.js, it works on my little fanless ARM Linux machines too.

Apr 232016
Vagrant - First Impressions

When you need a VM, you just build one manually. When you need two, you just build two manually. When you need three or more and with changing network topologies, you wonder if there is no better way to do this.

I needed 4 VMs: 1 doing NAT/acting as a router, and 3 for a typical cluster stuff like etcd, cassandra, object storage etc.
So something better than manual build was needed. OpenStack is a possible solution but that turned out to be surprisingly complicated and overkill. Vagrant looked better.

Things I learned so far:

  • Using Vagrant for a simple VM “out of the box” (“box” is basically the template) is very simple.
  • You connect to the single VM by “vagrant ssh”
  • Similar to Docker, you can import files (e.g. config files) and run scripts inside the VM
config.vm.provision "shell", inline: <<-SHELL
    date >/tmp/f0
  • Similar to Docker, you can mount local directories into the VM:
 config.vm.synced_folder "./data", "/vagrant"
  • Modifying VM parameter is not difficult:
config.vm.provider "virtualbox" do |vb|
  # Display the VirtualBox GUI when booting the machine
  # vb.gui = true
  # Customize the amount of memory on the VM:
  vb.memory = "512"
  vb.cpus = 1
  vb.linked_clone = true
  vb.customize ["modifyvm", :id, "--vram", "9"]
  • To modify an existing box or making a new one, you can do that manually, or via a “packer”. The manual one is easy:
    • Enter an existing box (easiest one: console, account vagrant, same password)
    • Do your stuff
    • Outside the box run:
vagrant package --base VMNAME
mv package.box some-more-sensible-name.box
vagrant box add some-more-sensible-name.box some-name
  • You can now use “some-name” as box name for new VMs
  • Keep the box files. And the Vagrantfile. That’s all beside replicated/copied/mounted directories.
  • Multiple VMs are easily created, and need some extra network configuration. Like this:
config.vm.define "web" do |web|

config.vm.define "db" do |db|
  • Since I have 2 bridged interfaces, I have to name the one I like. Both VMs promptly aquire IPs via DHCP on my internal network.
config.vm.network "public_network", bridge: "enp3s0"

Additional interesting links:





 Posted by at 23:21  Tagged with:
Apr 072016

Today we got an email from our Internet provider that we seem to attack an IP address within the provider’s network. Seemed to attack port 53. They ask us to check for viruses etc. The provider is Japanese, so the email was naturally Japanese too. Did not make it easier to understand for me.

Everyone knows, port 53 is DNS. Why would we or a virus try to connect port 53 on a non-server?

I checked all computers (the Windows machines was a natural first suspect), but all was clean. And then it dawned me: DNS Amplification attack! Using our router.
A quick check on the router showed more activity than normal, so it was confirmed that the router is the culprit.
The NAT connection table then promptly showed about 2000 connections with more and more being created while old ones were closed due to inactivity.

How to fix this? Disable remote DNS requests! Except remote is anything non-local to the router which also disabled the internal network from using DNS as all machines in our LAN use our router as DNS server (resp. relay).

The next attempt was better: set up the firewall to drop incoming DNS requests which come from the ppp interfaces.
Now I got about 50 active connections again (that’s normal), no odd DNS requests, and fw-dns-amp about 500 packets per second are being dropped. That accumulates quite fast. 280k packets dropped while writing this article.

The magic fix looks like this:

/ip firewall filter add chain=input action=drop protocol=udp in-interface=all-ppp dst-port=53 log=yes log-prefix=Ext-Incoming-DNS

That was interesting. Relatively easy to defeat. I’m surprised this is not configured by default, but then, I have a rather non-user-oriented router where it’s expected that the admin knows what he’s doing…
I’ll have to look a bit more into security of the router in regards to DoS attacks and logging and notifications for unusual traffic.