Archive

Archive for October, 2012

Plugwise Protocol Analysis, Part 6 (Firmware update observations)

7 October 2012 4 comments

Last year, there was a new firmware release for the PlugWise system. Curious as I was, I captured the communication between “Source” and the “Stick”as I did for the other protocol analysis sessions. Today I found me notes about this and document them here. The intention of this is to discover possible new commands used by the Plugwise protocol, some of them might be useful for open source implementations of software to use the “Circles”. I do NOT think uploading firmware should be done through our own software, but it is nice to know how it works.

As I captured this data quite a while ago, I am not sure anymore how complete all this is.

Update Firmware

After I got a message in “Source” that new firmware was available, I captured the chatter between “Source” and “Stick”. This update did update everything it could find, and tore down the old network and configured a new one. This is different from just updating a new module in your network. Probably, because some parts of the mesh-network protocol changed, or just because the “Stick” and/or the “Circle+” need an update, so the mesh-network is reset.

Analysis if the Firmware update process to firmware 2011
Summary of firmware versions as reported by the 0024 response

Before the update,  running firmware 2010

  • Stick    653907008510 4CCEC22A 00
  • Circle+    653907007324 4CCEBFA1 01
  • Circle    653907014023 4CCEC0C2 02

After the update, running firmware 2011

  • Stick    653907008510 4DCCDA69 00
  • Circle+    653907007324 4DCCDAF3 01
  • Circle    653907014023 4DCCDB7B 02

Other remarks

  1. Network ID changed (modified circle+ address)
    • Before update
      • LongPAN:060D6F0000B1B64B
      • ShortPAN:1606
    • After update
      • LongPAN:8A0D6F0000B1B64B
      • ShortPAN:3B8A
  2. Internal archive buffers
    • all buffers cleared
    • first bufferaddress is 0x00044000 (same)

What happens when the software starts:

1) Initialization sequence. Gets some basic data for the software
1a)    Initialization request to the stick with the 000A/0011 sequence
1b)    Identification request to the stick with the 0023/0024 sequence
This gives the PAN id and the stick-address and the firmware version of the stick.
1c)    Request to Circle+ (software must know address) with 004E/0000 sequence (gives a status 00F4)
2a)    Initialization request to the stick with the 000A/0011 sequence
2b)    Identification request to the stick with the 0023/0024 sequence (repeats 2 or 3 times, reason unknown)
2c)    Identification request to the Circle+ with the 0023/0024 sequence
2d)    Time-sync with Circle+ 0016/0000 and 0028/0000 sequences
2e)    Other setting to Circle+ 004A/0000 (poll interval an probably something else)
2f)    Then a sequences 0029/003A, 003E/003F to the Circle+
2g)    Send the reset code 0008 00/0000, position changes between tests, somewhere after the 004A/0000 sequence
2h)    For ‘source software’, normal scanning starts (0023/0024;0012/0013, later also 0048/0049)

When running the firmware update software, instead of normal scanning an inventory of modules is done with 0018/0019 for 64 modules (this seems the maximum number of modules, but I am not sure of this)

3a)    scanning for available modules with 0018/0019
3b)    query Stick and Circle+ with 0023/0024 sequence
3c)    reset code 0008 01/0000
3d)    query normal Circles with 0024/0023 sequence (once each)
3e)    send reset code 0008 00/0000, twice

4a)    query all normal Circles with 0023/0024 then 000C/0010 (gives firmware version)
4b)    query Circle+ with 0023/0024 then 000C/0010 (gives firmware version)
4c)    query Stick with 0023/0024 then 000C/0010 (gives firmware version)
4d)    send reset code 0008 00/0000

Update Stick

5) get firmware version (request and reply)
SEND    000C 000D6F0000B835CB
RECV    0000 0076 00C1
RECV    0010 0076 000D6F0000B835CB 4CCEC22A

The 000C/0010 sequence is always preceded by a 0023/0024 sequence, both reports the old firmware level.

After the firmware update this check is done again, then the 0010 reports the new firmware version (loaded and ready to start i assume) and the 0024 reports the old firmware version (the running version)
This phase is probably the checking phase of a firmware update.
It starts with an 0008 reset, then queries the circles, then circle+, then stick, then another 0008 reset.

6) First firmware upload (bootloader?) to the stick
6a) a few checks
SEND    0023 000D6F0000B835CB
RECV    0000 0075 00C1
RECV    0024 0075 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

SEND    000C 000D6F0000B835CB
RECV    0000 0076 00C1
RECV    0010 0076 000D6F0000B835CB 4CCEC22A

6b) this prepares for the firmware upload, I assume
SEND    000B 000D6F0000B835CB
RECV    0000 0077 00C1
RECV    0003 0077 00CF    *** -=-Pair/unpair/confirm-=- ***

6c) send firmware/bootloader image
... binary data, not the typical ascii-hex data ... (bootloader, firmware)
6d) a few checks again
SEND    0023 000D6F0000B835CB
RECV    0000 0078 00C1
RECV    0024 0078 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

SEND    000C 000D6F0000B835CB
RECV    0000 0079 00C1
RECV    0010 0079000D6F0000B835CB 4DCCDB7B

Update Circle+

SEND    000F 000D6F0000D3595D023C
RECV    0000 015A 00C1
RECV    0000 015A 00E8 000D6F0000D3595D


Somewhere here the network was torn down and the new firmware uploaded, then the network is rebuild.
No need to analyze the firmware upload on the windows side, as you need the windows software+license anyway.
Could not find the firmware files on disk, so I assume they are held in memory.
Anyway, the circles are updated so that does not mater.

RECV    0006 0003 CircleMAC

SEND    0023 CircleMAC
RECV    0000 0020 00E1

SEND    0007 01 CircleMAC
...
SEND    0023 CircleMAC

****    RECV    0061 FFFD CircleMAC
****    Received the 0061 broadcast between other chatter

RECV    0024 00DB CircleMAC 00010002 00048B28 01 85 653907014023 4DCCDB7B 02
(the clock is uninitialized)

SEND    0016 CircleMAC 0B07923C 00044000 4000 17380D 02
here the time is SET, and reset buffers too
RECV    0000 00DC 00D7 CircleMAC

SEND    0023 CircleMAC
RECV    0024 00DD CircleMAC 0B07923C 00044000 01 85 653907014023 4DCCDB7B 02

SEND    005F CircleMAC
RECV    0060 00DE CircleMAC FFFFFFFFFFFFFFFE

SEND    0057 CircleMAC 003C 0000
RECV    0000 00DF 00F8 CircleMAC
...
SEND    0058 CircleMAC 01
RECV    0000 0123 00F9 CircleMAC


SEND    0023 CircleMAC
RECV    0024 0130 CircleMAC 0B07923E 00044000 01 85 653907014023 4DCCDB7B 02


SEND    0040 CircleMAC 00 01
RECV    0000 0131 00E5 CircleMAC

Conclusion

A plugwise device can have it’s firmware loaded in a buffer and it is activated by a ‘reboot’. Maybe you can switch between 2 firmwares, as can also be done with some other ’embedded’ devices, as kind of fail-save mechanism.  Firmware is uploaded to each device separately.

After flashing new firmware the module is reset and all configuration data (like schakel schema’s) are uploaded again.

Advertisements
Categories: Domotica Tags: ,

Linux Samba with CIFS and Windows Home Server

7 October 2012 Leave a comment

Last year I experimented with a borrowed NAS  and wanted to use it as a backup for my windows home server. At home most of my computers run linux and I wanted to map those shares automatic on my main desktop. Not wanting to re-invent a wheel again, I did a google search and found this:

http://www.digiplace.nl/2011/01/27/hoe-verbind-je-ubuntu-automatisch-met-een-samba-share-op-een-qnap-nas/

So I needed to put the following lines in  /etc/fstab, or for testing, something similar after the sudo mount command

my Nas (all on the same line):
//nas/data /media/nas cifs credentials=/root/.naslogin, rw,iocharset=utf8,dir_mode=0777,file_mode=0777 0 0

My Homeserver (all on the same line):
//whs/ebooks /media/whs/ebooks cifs credentials=/root/.whslogin, rw,iocharset=utf8,dir_mode=0777,file_mode=0777 0 0

This worked for my NAS but not for my windows home server.  Mounting the share from the home server  failed . It just trow an error: “mount error(5): Input/output error“, that pointed to the right solution. NOT!

After some searching, I found the reason. I was not using the netbios name for the windows server, but an alias.

http://lists.samba.org/archive/linux-cifs-client/2005-January/000649.html

What happened.

Mounting the share failed because windows refused the connection. The internal netbios name of my home server did not match the name in the mount command.

Remember that for windows, the computer name is also the netbios name, and the home server is running Windows Home Server (i.e. Windows 2003). I decided to have a dns name for my home server different than the internal computer name, so there was a mismatch.

Once I knew the cause, the solution to this was easy. Just use the same computer name as the computer thinks it has, and not something else 🙂 even through that other name resolves to the same computer. After adding the netbios name of my home server to the hosts file on linux and using the netbios name in the mount command, it worked.

sudo mount -t cifs //roheve/ebooks /media/whs/ebooks -o credentials=/root/.whslogin,iocharset=utf8,dir_mode=0777,file_mode=0777,nounix

And now it ‘just works’.

PS: I need to remember these to (copy_n_paste is easy)

sudo mount -t cifs //sw-hy1.testlab.local/c$/data /media/testlab/hy1 -o credentials=/root/.testlab,iocharset=utf8,dir_mode=0777,file_mode=0777,nounix

sudo mount -t cifs //sw-hy2.testlab.local/data /media/testlab/hy2 -o credentials=/root/.testlab,iocharset=utf8,dir_mode=0777,file_mode=0777,nounix

Categories: Linux, Windows Tags: , , ,