Here is a quick writeup of the protocol for the iKettle taken from my Google+ post earlier this month. This protocol allows you to write your own software to control your iKettle or get notifications from it, so you can integrate it into your desktop or existing home automation system.
The iKettle is advertised as the first wifi kettle, available in UK since February 2014. I bought mine on pre-order back in October 2013. When you first turn on the kettle it acts as a wifi hotspot and they supply an app for Android and iPhone that reconfigures the kettle to then connect to your local wifi hotspot instead. The app then communicates with the kettle on your local network enabling you to turn it on, set some temperature options, and get notification when it has boiled.
Once connected to your local network the device responds to ping requests and listens on two tcp ports, 23 and 2000. The wifi connectivity is enabled by a third party serial to wifi interface board and it responds similar to a HLK-WIFI-M03. Port 23 is used to configure the wifi board itself (to tell it what network to connect to and so on). Port 2000 is passed through to the processor in the iKettle to handle the main interface to the kettle.
|Bit 6||Bit 5||Bit 4||Bit 3||Bit 2||Bit 1|
So, for example if you receive "sys status key=!" then buttons "100C" and "On" are currently active (and the kettle is therefore turned on and heating up to 100C).
|sys status 0x100||100C selected|
|sys status 0x95||95C selected|
|sys status 0x80||80C selected|
|sys status 0x100||65C selected|
|sys status 0x11||Warm selected|
|sys status 0x10||Warm has ended|
|sys status 0x5||Turned on|
|sys status 0x0||Turned off|
|sys status 0x8005||Warm length is 5 minutes|
|sys status 0x8010||Warm length is 10 minutes|
|sys status 0x8020||Warm length is 20 minutes|
|sys status 0x3||Reached temperature|
|sys status 0x2||Problem (boiled dry?)|
|sys status 0x1||Kettle was removed (whilst on)|
You can receive multiple status messages given one action, for example if you turn the kettle on you should get a "sys status 0x5" and a "sys status 0x100" showing the "on" and "100C" buttons are selected. When the kettle boils and turns off you'd get a "sys status 0x3" to notify you it boiled, followed by a "sys status 0x0" to indicate all the buttons are now off.
|set sys output 0x80||Select 100C button|
|set sys output 0x2||Select 95C button|
|set sys output 0x4000||Select 80C button|
|set sys output 0x200||Select 65C button|
|set sys output 0x8||Select Warm button|
|set sys output 0x8005||Warm option is 5 mins|
|set sys output 0x8010||Warm option is 10 mins|
|set sys output 0x8020||Warm option is 20 mins|
|set sys output 0x4||Select On button|
|set sys output 0x0||Turn off|
If you're interested in looking at the web interface you can enable it by connecting to port 23 using telnet or nc, entering the password, then issuing the commands "AT+WEBS=1\n" then "AT+PMTF\n" then "AT+Z\n" and then you can open up a webserver on port 80 of the kettle and change or review the settings. I would not recommend you mess around with this interface, you could easily break the iKettle in a way that you can't easily fix. The interface gives you the option of uploading new firmware, but if you do this you could get into a state where the kettle processor can't correctly configure the interface and you're left with a broken kettle. Also the firmware is just for the wifi serial interface, not for the kettle control (the port 2000 stuff above), so there probably isn't much point.
We were looking for a cheap laser lighting effect for our weekend parties and saw one that looked impressive, the Lanta Quasar Buster 2, and for only £30 new. The unit has both a red and green laser and and a nice moving effect that looks like the beams splits up and recombine again. It promised "sound activation" and we thought that meant it would do some clever sound to light effect, but it really does mean sound activation and just turns itself on when it hears a sound, then off again when it's silent. So out of the box the laser has three modes; the first lets you just set the speed of the effect with the lasers constantly on, the second strobes the lasers on and off to a speed you can set, and the third is the usless sound activation mode.
Warrany void if removed. I didn't technically "remove" the sticker though.
Opening the unit showed that it was easily hackable; all the connections to the control panel were via connectors. One connector provides +5v to the cooling fan, another +5v to a separate board that handles powering the two lasers, another connects to the motor the turns the optics to produce the burst effect, and the final one has a logic level signal to tell the laser power board if the lasers should be on or off.
Since the laser power board is completely separate we can just replace this control panel with one of our own and then we can control the laser on/off and the speed of the motor (actually we could control the direction too but it doesn't really make the effect look any better so I leave it as one direction). And we can always swap the original board back in the future.
My new control board comprises of an Arduino pro mini compatible board, a rotary encoder for setting the mode and levels, a mic with simple opamp preamp, and a MSGEQ7 chip to do all the hard work of analysing the levels of various frequencies. The optics motor is now simply driven using a PWM output via a MOSFET I had spare.
Rough source and circuit diagram are available from github; some components don't have values if it doesn't really matter and others (like the MOSFET) can be changed as I just used things I happened to have in my component boxes. I'm still playing with different effects in software to see what works best.
"for all packages, from release of 6.3 up to and including 6.4, we shipped 108 advisories to address 311 vulnerabilities. 18 advisories were rated critical, 28 were important, and the remaining 62 were moderate and low."
"Updates to correct 77 of the 78 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The other one was in OpenJDK 1.60 where the update took 4 calendar days (over a weekend)."
And if you are interested in how the figures were calculated, here is the working out:
Note that we can't just use a date range because we've pushed some RHSA the weeks before 6.4 that were not included in the 6.4 spin. These issues will get included when we do the 6.4 to 6.5 report (as anyone installing 6.4 will have got them when they first updated).
So just after 6.4 before anything else was pushed that day:** Product: Red Hat Enterprise Linux 6 server (all packages) ** Dates: 20101110 - 20130221 (835 days) ** 397 advisories (C=55 I=109 L=47 M=186 ) ** 1151 vulnerabilities (C=198 I=185 L=279 M=489 ) ** Product: Red Hat Enterprise Linux 6 Server (default installation packages) ** Dates: 20101110 - 20130221 (835 days) ** 177 advisories (C=11 I=71 L=19 M=76 ) ** 579 vulnerabilities (C=35 I=133 L=159 M=252 )
And we need to exclude errata released before 2013-02-21 but not in 6.4:RHSA-2013:0273 [critical, default] RHSA-2013:0275 [important, not default] RHSA-2013:0272 [critical, not default] RHSA-2013:0271 [critical, not default] RHSA-2013:0270 [moderate, not default] RHSA-2013:0269 [moderate, not default] RHSA-2013:0250 [moderate, default] RHSA-2013:0247 [important, not default] RHSA-2013:0245 [critical, default] RHSA-2013:0219 [moderate, default] RHSA-2013:0216 [important, default] Default vulns from above: critical:12 important:2 moderate:16 low:3 Non-Default vulns from above: critical:4 important:2 moderate:5 low:0
This gives us "Fixed between GA and 6.4 iso":** Product: Red Hat Enterprise Linux 6 server (all packages) ** Dates: 20101110 - 20130221 (835 days) ** 386 advisories (C=51 I=106 L=47 M=182 ) ** 1107 vulnerabilities (C=182 I=181 L=276 M=468 ) ** Product: Red Hat Enterprise Linux 6 Server (default installation packages) ** Dates: 20101110 - 20130221 (835 days) ** 172 advisories (C=9 I=70 L=19 M=74 ) ** 546 vulnerabilities (C=23 I=131 L=156 M=236 )
And taken from the last report "Fixed between GA and 6.3 iso":** Product: Red Hat Enterprise Linux 6 server (all packages) ** Dates: 20101110 - 20120620 (589 days) ** 278 advisories (C=33 I=78 L=31 M=136 ) ** 796 vulnerabilities (C=104 I=140 L=196 M=356 ) ** Product: Red Hat Enterprise Linux 6 Server (default installation packages) ** Dates: 20101110 - 20120620 (589 days) ** 134 advisories (C=6 I=56 L=15 M=57 ) ** 438 vulnerabilities (C=16 I=110 L=126 M=186 )
Therefore between 6.3 iso and 6.4 iso:** Product: Red Hat Enterprise Linux 6 server (all packages) ** Dates: 20120621 - 20130221 (246 days) ** 108 advisories (C=18 I=28 L=16 M=46 ) ** 311 vulnerabilities (C=78 I=41 L=80 M=112 ) ** Product: Red Hat Enterprise Linux 6 Server (default installation packages) ** Dates: 20120621 - 20130221 (246 days) ** 38 advisories (C=3 I=14 L=4 M=17 ) ** 108 vulnerabilities (C=7 I=21 L=30 M=50 )
Note: although we have 3 default criticals, they are in openjdk-1.6.0, but we only call Java issues critical if they can be exploited via a browser, and in RHEL6 the Java browser plugin is in the icedtea-web package, which isn't a default package. So that means on a default install you don't get Java plugins running in your browser, so really these are not default criticals in RHEL6 default at all.
"for all packages, from release of 6.2 up to and including 6.3, we shipped 88 advisories to address 233 vulnerabilities. 15 advisories were rated critical, 23 were important, and the remaining 50 were moderate and low."And if you are interested in how the figures were calculated, as always view the source of this blog entry.
"Updates to correct 34 of the 36 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The Kerberos telnet flaw was fixed in 2 calendar days as the issue was published on Christmas day. The second PHP flaw took 4 calendar days (over a weekend) as the initial fix released upstream was incomplete."
I was booked to go to Red Hat HQ in Raleigh, NC at the start of August for a two-day business trip, well more accurately two-days in the office and another two-days of travelling. I'd usually take my trusty ThinkPad x201 on the trip with me, it's small and light, but it's battery life isn't so great anymore. Earlier this year I'd bought an Android tablet, an ASUS Transformer Prime which with a long battery life would be perfect for movies, but could it replace my ThinkPad completely and save me travelling with two devices? I worked through my requirements and it seemed plausible in theory, so here is how it stacked up in practice:
So in summary I think I got away with it; having just the tablet didn't stop me doing anything that had to be done on the trip and I'll definately do the same thing again in the future for very short trips. For anything more than a couple of days or where connectivity might be an issue I'd miss having a full-featured OS.
So last year I obtained an Archos 101 10.1" android tablet with the plan being to replace the existing tablets with android powered ones. It was a good excuse to dust off the old skills and learn programming apps for Android. Converting the app was straightforward and tooks a couple of weekends, troubles with the tablet took quite a bit more work.
Finding a way to mount the Archos tablet on a wall proved tricky, the back of the device isn't perfectly flat and it has an annoying desk stand in the middle. I ended up using a PadTab for mounting, but having to custom modify it to handle not being in the centre of the device, and add thick sticky strips (normally used to dampen fans). The build quality of these tablets is pretty poor.
The display panel on the tablet isn't very good either and has limited viewing angles from three sides, so in order to be able to see the screen when mounted to the wall I had to turn it upside down. Android can happily handle a rotated display, the only downside is that the Archos logo is the wrong way up (a bit of black tape covers it up now).
I left the Archos mounted on the wall and running for a week, permanently attached to its charger. At the end of the week I noticed it wasn't sitting straight on the wall, and in fact the internal batteries had both swelled up and burst out of the case. I read online a few other stories from folks who had bought Archos tablets which had failed in the same way, I guess they're really not designed to be left on charge permanently (that's really bad design Archos, this could have easily caught fire!)
I figured I didn't really need to have batteries installed, the tablet is going to be permanently powered on anyway, and it would be safer to leave the house knowing there was no risk of exploding batteries. So I took the tablet apart and removed them. Without batteries the Archos starts its power up cycle, displays a logo, then gets to a certain part of the boot process and powers down. I guess it does a check on the state of the batteries and it fails. This presented a real problem and I gave up trying to use the tablet. Over the Christmas holidays I heard that you could flash an alternative OS, CyanogenMod, and that actually booted and ran just fine without batteries, but it wasn't stable and featured enough for running the Home Automation app I'd written.
So I decided to try to debug the Archos OS, so connected it to USB to get debug messages, and interestingly it powered up perfectly first time. Removing the USB connection caused it to lock up a few seconds later. Strange behaviour! I tried just connecting power to the USB port, and that worked too. So if you want to run your Archos 101 android tablet without internal batteries you can, but you need to splice your power cable and feed 5v to both the power socket and the USB socket.
So now I had a working tablet again I changed the power adaptor so it mounted neatly against the wall:
Here are a couple of pics of it in use:
Red Hat Enterprise Linux 5 is coming up to its fifth year since release, and is supported for another five years, until 2017.
The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 5 Server if you had installed 5.7, up to and including the 5.8 release, broken down by severity. It's split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve quite a bit of manual effort to select every one). For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what packages you have installed or removed.
So, for a default install, from release of 5.7 up to and including 5.8, we shipped 42 advisories to address 118 vulnerabilities. 4 advisories were rated critical, 13 were important, and the remaining 25 were moderate and low.
Or, for all packages, from release of 5.7 up to and including 5.8, we shipped 71 advisories to address 177 vulnerabilities. 7 advisories were rated critical, 16 were important, and the remaining 48 were moderate and low.
The 7 critical advisories addressed 20 critical vulnerabilities across 4 different packages:
Updates to correct 19 out of the 20 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The update to krb5 took 2 calendar days because it was public on Christmas day.
Overall, for Red Hat Enterprise Linux 5 since release until 5.8, 98% of critical vulnerabilities have had an update available to address them available from the Red Hat Network either the same day or the next calendar day after the issue was public.
Although not in the definition of critical severity, also of interest during this period were a couple of remote denial of service flaws that were easily exploitable:
To compare these statistics with previous update releases we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:
This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but isn't really useful for comparisons with other major versions, distributions, or operating systems -- for example, a default install of Red Hat Enterprise Linux 4AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.