The best known smart bulb setups (such as the Philips Hue and the Belkin Wemo) are based on Zigbee, a low-energy, low-bandwidth protocol that operates on various unlicensed radio bands. The problem with Zigbee is that basically no home routers or mobile devices have a Zigbee radio, so to communicate with them you need an additional device (usually called a hub or bridge) that can speak Zigbee and also hook up to your existing home network. Requests are sent to the hub (either directly if you're on the same network, or via some external control server if you're on a different network) and it sends appropriate Zigbee commands to the bulbs.
But requiring an additional device adds some expense. People have attempted to solve this in a couple of ways. The first is building direct network connectivity into the bulbs, in the form of adding an 802.11 controller. Go through some sort of setup process[1], the bulb joins your network and you can communicate with it happily. Unfortunately adding wifi costs more than adding Zigbee, both in terms of money and power - wifi bulbs consume noticeably more power when "off" than Zigbee ones.
There's a middle ground. There's a large number of bulbs available from Amazon advertising themselves as Bluetooth, which is true but slightly misleading. They're actually implementing Bluetooth Low Energy, which is part of the Bluetooth 4.0 spec. Implementing this requires both OS and hardware support, so older systems are unable to communicate. Android 4.3 devices tend to have all the necessary features, and modern desktop Linux is also fine as long as you have a Bluetooth 4.0 controller.
Bluetooth is intended as a low power communications protocol. Bluetooth Low Energy (or BLE) is even lower than that, running in a similar power range to Zigbee. Most semi-modern phones can speak it, so it seems like a pretty good choice. Obviously you lose the ability to access the device remotely, but given the
track record on
this sort of thing that's arguably a benefit. There's a couple of other downsides - the range is worse than Zigbee (but probably still acceptable for any reasonably sized house or apartment), and only one device can be connected to a given BLE server at any one time. That means that if you have the control app open while you're near a bulb, nobody else can control that bulb until you disconnect.
The quality of the bulbs varies a great deal. Some of them are pure RGB bulbs and incapable of producing a convincing white at a reasonable intensity[2]. Some have additional white LEDs but don't support running them at the same time as the colour LEDs, so you have the choice between colour or a fixed (and usually more intense) white. Some allow running the white LEDs at the same time as the RGB ones, which means you can vary the colour temperature of the "white" output.
But while the quality of the bulbs varies, the quality of the apps doesn't really. They're typically all dreadful, competing on features like changing bulb colour in time to music rather than on providing a pleasant user experience. And the whole "Only one person can control the lights at a time" thing doesn't really work so well if you actually live with anyone else. I was dissatisfied.
I'd met
Mike Ryan at
Kiwicon a couple of years back after watching him demonstrate hacking a BLE skateboard. He offered a couple of good hints for reverse engineering these devices, the first being that Android already does almost everything you need. Hidden in the developer settings is an option marked "Enable Bluetooth HCI snoop log". Turn that on and all Bluetooth traffic (including BLE) is dumped into /sdcard/btsnoop_hci.log. Turn that on, start the app, make some changes, retrieve the file and check it out using Wireshark. Easy.
Conveniently, BLE is very straightforward when it comes to network protocol. The only thing you have is GATT, the Generic Attribute Protocol. Using this you can read and write multiple characteristics. Each packet is limited to a maximum of 20 bytes. Most implementations use a single characteristic for light control, so it's then just a matter of staring at the dumped packets until something jumps out at you. A pretty typical implementation is something like:
0x56,r,g,b,0x00,0xf0,0x00,0xaa
where r, g and b are each just a single byte representing the corresponding red, green or blue intensity. 0x56 presumably indicates a "Set the light to these values" command, 0xaa indicates end of command and 0xf0 indicates that it's a request to set the colour LEDs. Sending 0x0f instead results in the previous byte (0x00 in this example) being interpreted as the intensity of the white LEDs. Unfortunately the bulb I tested that speaks this protocol didn't allow you to drive the white LEDs at the same time as anything else - setting the selection byte to 0xff didn't result in both sets of intensities being interpreted at once. Boo.
You can test this out fairly easily using the gatttool app. Run hcitool lescan to look for the device (remember that it won't show up if anything else is connected to it at the time), then do gatttool -b deviceid -I to get an interactive shell. Type connect to initiate a connection, and once connected send commands by doing char-write-cmd handle value using the handle obtained from your hci dump.
I did this successfully for various bulbs, but annoyingly hit a problem with one from
Tikteck. The leading byte of each packet was clearly a counter, but the rest of the packet appeared to be garbage. For reasons best known to themselves, they've implemented application-level encryption on top of BLE. This was a shame, because they were easily the best of the bulbs I'd used - the white LEDs work in conjunction with the colour ones once you're sufficiently close to white, giving you good intensity and letting you modify the colour temperature. That gave me incentive, but figuring out the protocol took quite some time. Earlier this week, I finally cracked it. I've put a Python implementation
on Github. The idea is to tie it into
Ulfire running on a central machine with a Bluetooth controller, making it possible for me to control the lights from multiple different apps simultaneously and also integrating with my Echo.
I'd write something about the encryption, but I honestly don't know. Large parts of this make no sense to me whatsoever. I haven't even had any gin in the past two weeks. If anybody can explain how anything that's being done there makes any sense at all[3] that would be appreciated.
[1] typically via the bulb pretending to be an access point, but also these days through a terrifying hack involving spewing UDP multicast packets of varying lengths in order to broadcast the password to associated but unauthenticated devices and good god the future is terrifying
[2] For a given power input, blue LEDs produce more light than other colours. To get white with RGB LEDs you either need to have more red and green LEDs than blue ones (which costs more), or you need to reduce the intensity of the blue ones (which means your headline intensity is lower). Neither is appealing, so most of these bulbs will just give you a blue "white" if you ask for full red, green and blue
[3] Especially the bit where we calculate something from the username and password and then encrypt that
using some random numbers as the key, then send 50% of the random numbers and 50% of the encrypted output to the device, because I can't even
comments
Lars wrote about the remote debugging problem.
I write free software and I have some users. My primary support
channels are over email and IRC, which means I do not have direct
access to the system where my software runs. When one of my users has
a problem, we go through one or more cycles of them reporting what
they see and me asking them for more information, or asking them to
try this thing or that thing and report results. This can be quite
frustrating.
I want, nay, need to improve this. I've been thinking about this for a
while, and talking with friends about it, and here's my current ideas.
First idea: have a script that gathers as much information as
possible, which the user can run. For example, log files, full
configuration, full environment, etc. The user would then mail the
output to me. The information will need to be anonymised suitably so
that no actual secrets are leaked. This would be similar to Debian's
package specific reportbug scripts.
Second idea: make it less likely that the user needs help solving
their issue, with better error messages. This would require error
messages to have sufficient explanation that a user can solve their
problem. That doesn't necessarily mean a lot of text, but also code
that analyses the situation when the error happens to include things
that are relevant for the problem resolving process, and giving error
messages that are as specific as possible. Example: don't just fail
saying "write error", but make the code find out why writing caused an
error.
Third idea: in addition to better error messages, might provide
diagnostics tools as well.
A friend suggested having a script that sets up a known good set of
operations and verifies they work. This would establish a
known-working baseline, or smoke test, so that we can rule things like
"software isn't completely installed".
Do you have ideas? Mail me (liw@liw.fi) or tell me on identi.ca (@liw)
or Twitter (@larswirzenius).
2. Replace the bash code that produced the left navigation on the 
)
3. Thought hard about navigation of the test website, and redesigned (by rearranging) links in the left hand navigation.
After code review, you will see these changes as well! Things to look forward to include:
Around a year ago, I started hacking together a machine readable version
of the OSI approved licenses list, and casually picking parts up until it
was ready to launch. A few weeks ago, we officially announced
the 
Japanese authors have a tendency to commit suicide, it seems. I have read 
Considered as Dazai s master piece, and with Soseki s Kokoro the best selling novels in Japan. The book recounts the life of Oba Yozo, from childhood to the end in a mental hospital. The early years, described in the first chapter ( Memorandum ), are filled with the feeling of differentness, alienation from the rest, and Oba starts his way of living by playing the clown, permanently making jokes. The Second Memorandom spans the time to university, where he drops out, tries to become a painter, indulges in alcohol, smoking and prostitutes, leading to a suicide attempt together with a married woman, but he survived. The first part of the Third Memorandom sees a short recovering due to his relationship with a woman. He stops drinking and works as cartoonist, but in the last part his drinking pal from university times shows up again and they return into an ever increasing vicious drinking. Eventually he is separated from his wife, and confined to a mental hospital.
Very depressing to read, but written in a way that one cannot stop reading. The disturbing thing about this book is that, although the main actor conceives many bad actions, we feel somehow attached to him and feel pity for him. It is somehow a exercise how circumstances and small predispositions can make a huge change in our lives. And it warns us that each one of us can easily come to this brink.
Is package foo a key package (yet)?
Currently, Let's Encrypt's certbot tool issues certificates to servers running on TCP port 443 or 80. These are considered to be a 
Over the past year I ve been refining my understanding of the core
claims of Kantian ethics. I ve realised that I have deeply Kantian
intuitions about a lot of issues, and I understand these intuitions
better now that I can put them in Kantian terms. Consider two
exercises of state power: riot police suppressing protesters by
non-lethal means, and soldiers shooting protesters to death. I feel
more uncomfortable thinking about the first: there s something
altogether more sinister about it than the second, even though the
second is much more sad.
I think that the reason is that non-lethal weaponry is designed to
take away people s agency, and it often achieves this aim by means of
emotional manipulation. Riot police use so-called baton charges to
incite fearful retreat. Protesters have reasoned that in their
political situation, they have a duty to resist the incumbent
government. Riot police seek to unseat this conviction and cause fear
to determine what the protesters will do. In Kantian terms, the
riot police fail to respect the moral agency of the protesters by
seeking to unseat the moral personality s determination of what the
protester will do.
A controversial example that Kant uses to make this point is the axe
murderer case. Kant asks us to imagine that someone bangs on our
front door and begs us to hide him in our house, because someone who
wishes to kill him is coming up behind them. We do so. When the axe
murderer arrives, he goes door-to-door and asks us whether the
intended victim is in each house. Kant says that it is morally wrong
to lie to the axe murderer and say that the victim is not in your
house. How could this be? Surely there is a moral duty to protect
the victim from being killed? Indeed there is, but when it comes into
conflict with the duty not to lie, that second duty wins out. That s
because respecting the moral agency of individuals is paramount. In
this case, we would fail to respect the murderer s agency if we didn t
allow him to take the decision to murder or not murder the victim; by
lying to him we (disrespectfully) bypass his choice as to whether to
do it.
It s obviously crazy to say that we are morally required to give up
the victim. Kant gives the wrong answer in this case. However, the
case definitely reveals a requirement to respect other people s view
of what they should do, and give them a chance to do it. Similarly it
seems like we shouldn t give semi-automatics to our riot police, but
there s something wrong with a lot of what they do.
During the recent campaigns about Britain s EU referendum, some
criticised Jeremy Corbyn s campaigning on the grounds that he failed
to make an emotional appeal, instead asking people to make their own
rational decision when they come to cast their vote. So he lost out
the emotional appeals other people were making. It seems that he was
successfully respecting individual agency. You ve got to give people
a chance to live up to their own idea of what they should do.
I m not sure how to reconcile these various ideas, and I m not sure
what it says about me that I find non-lethal weaponry as uncomfortable
as I do.
How to help
A good first step is simply looking over the 
