Philips Hue 2.1 – Enabling WIFI

First of all this is my first blog post. The idea behind this was that information regarding rooting the 2.1 bridge from Philips is scarce across multiple blogs, githubs, youtube uploads and reddit topics. The full solution was not yet documented.

I will mention all my sources of information at the end of article.

So let’s begin with the bridge disassembly.

You will find two hex screws at the bottom of the bridge. Just pop off those rubber parts with a flat screwdriver and you will see them.

Get yourself a plastic card and pop off the back cover.

Remove the board from inside the case and inspect it.

You will need to solder a 6 header pin into the board. If you don’t have a soldering station please borrow one. The soldering operation takes 1 minute and the header can be left soldered into the board. The case fits perfectly with the header present.

The header goes into the J6 spot on the board.

Get yourself a FT232RL UART. I wasted 1 full day trying to figure out why it didn’t work with my CH340G.

With CH340G, in the first stage of the u-boot I had only artifacts on screen and the bridge got stuck in that sequence if the UART was plugged into the computer USB. I suspect a power drain. Here’s how it looked like:


Just use a FT232RL and you won’t have any issues. The UART needs to be set up for 3.3V usage. To make sure of this, measure between GND and RX, plus between GND and TX. You should see approx 3.3V.

On the Hue Bridge the mapping of the J6 header to UART and its pin-out is the following(starting from the top – which has a small triangle(GND)) :

Hue Bridge PIN OrderHue Bridge PIN MappingUSB to TTL Mapping
1GNDGND
2NOT USED
3NOT USED
4RXTX
5TXRX
6NOT USED

OPTIONAL: You could also measure between GND and TX(PIN 5) on the bridge and you will confirm the pin-out from above by seeing some voltage on your multi-meter.

Connect the UART to a computer, set the speed to 115200 and power on the Hue Bridge.

The first stage of the boot process looks like this:

After a while the boot sequence will finish and the logon prompt will be shown(if it’s not, hit Enter once or twice):

If the Enter key is recognized then TX from UART works and obiviously RX as well since you’re seeing messages on screen.

Now prepare a wire, or a paper clip. Remove the power from the Hue Bridge.

You will have to power on the bridge and after 2-3 seconds(that’s the amount of time the first stage of the u-boot takes to move to the second stage of the boot process – the FLASH chip) connect the GND of the hue board to the to the tip of solder behind SEU11.

Take a look at the options I’ve given below. Pick either one.

If you’re going to be successful and I don’t see a reason not to be, you will see this:

** Device 0 not available

simply means that the FLASH was bypassed and now we have access to the u-boot.

Run the following commands:

setenv bootdelay 3
saveenv
reset

This will allow you 3 seconds to enter the u-boot CLI without having to connect the wire which blocks the read of the flash memory.

We will now have to change the root account’s hash. But first make a local backup of the existing one. Someone mentioned that having the root password changed gave him some errors to the Hue Cloud services. I can’t confirm this but it doesn’t matter since we’ll leverage public key authentication with SSH and restore the hash later.

Run the command to print the hash then save it to a text file(use Notepad/Notepad++):

printenv security

Run the command to change the hash, thus changing the root password to “toor”:

setenv security '$5$wbgtEC1iF$ugIfQUoE7SNg4mplDI/7xdfLC7jXoMAkupeMsm10hY9'
saveenv
reset

Login to the Hue Bridge with “root/toor”.

Use puttygen to generate yourself an RSA 2048 key. Click on “Save private key” and then copy the string from the “Public key for pasting into OpenSSH authorized_keys file:“.

Create a file inside /root, on the bridge, and paste the public key contents. Run the following command to import the key:

ssh-factory-key -r key

where key is the file which contains the public key.

dropbear (the ssh daemon) will configure itself with the public key and the firewall daemon will receive the request to open up TCP:22. Wonderful!

Assuming you have the ethernet cable plugged in try and ssh to the Hue Bridge by using public key authentication. If you’re successful, then reboot the bridge and cancel the autoboot process once more.

Restore the old root hash which you’ve backed up previously and reset the unit.

As of now you can remove the UART device and assemble the unit back together.

You have accomplished the root the device and the enablement of SSH.

The Hue Bridge runs an OpenWRT version with some custom additions from Philips:

root@Philips-Hue:~# cat /etc/*release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Chaos Calmer'
DISTRIB_REVISION='r47070'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05.1'
DISTRIB_TAINTS='no-all busybox override'

The packages for the 15.05.1 distribution can be found over here.

The Hue Bridge supports only WEP authentication and assuming you and nobody else doesn’t use that old authentication scheme we’ll need to enable WPA2 support.

Unfortunately in this release (1801260942 – returned by cat /etc/swversion) they removed the opkg tool – openwrt’s package manager.

Download “wpad-mini_2015-03-25-1_ar71xx.ipk” and extract its contents on your computer.

Extract the wpad binary from the ipk archive (I’ve used 7zip) and copy it to /usr/sbin on the bridge (you can use WinSCP for example).

Make sure it has execute permissions:

chmod +x /usr/sbin/wpad

and create the following symlink:

ln -s /usr/sbin/wpad /usr/sbin/wpa_supplicant

If we run wpa_supplicant we’ll receive an error that it requires a missing library:

/lib/libm.so.0

I said earlier that the OpenWRT release has some customization and it’s not the original one. For instance libc is 1.0.14 and the standard build has the 0.9.33.2-1.

Bummer…

The good thing is that it seems wpa_supplicant is compatible with 1.0.14 as well. Let’s create the following symlinks:

ln -s /lib/libm-1.0.14.so /lib/libm.so.0
ln -s /lib/libuClibc-1.0.14.so  /lib/libc.so.0

Try and execute wpa_supplicant from the CLI once more. It should work and display the help menu.

Make a backup of the following configuration files:

cp /etc/config/firewall /etc/config/firewall.old
cp /etc/config/wireless /etc/config/wireless.old
cp /etc/config/hk_mdns /etc/config/hk_mdns.old

Fortunately the vim text editor is present. Let’s activate the wireless module by adding the following to the /etc/config/wireless file:

config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11ng'
option path 'platform/qca953x_wmac'
list ht_capab 'LDPC'
list ht_capab 'SHORT-GI-20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'TX-STBC'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option htmode 'HT20'
option disabled '0'

config wifi-iface
option device 'radio0'
option network 'wlan'
option encryption 'psk2'
option key 'REPLACE_ME'
option mode 'sta'
option ssid 'REPLACE_ME'

Put your own SSID and KEY values in the file.

Run the following commands:

uci commit wireless
wifi

To verify the connection status execute:

root@Philips-Hue:/etc/config# iw wlan0 link
Connected to 10:fe:ed:f3:e7:08 (on wlan0)
SSID: XXXXXX
freq: 2452
RX: 3837187 bytes (36354 packets)
TX: 843981 bytes (2859 packets)
signal: -56 dBm
tx bitrate: 135.0 MBit/s MCS 6 40MHz short GI

bss flags: short-preamble short-slot-time
dtim period: 1
beacon int: 100

Get an IP address with DHCP:

udhcpc -i wlan0

To make it persistent edit /etc/config/network and add at the end:

config interface 'wlan'

option ifname 'wlan0'
option proto 'dhcp'
option hostname 'Philips-Hue'

Also replace eth1 with wlan0 inside /etc/config/hk_mdns:

sed -i "s/eth1/wlan0/ /etc/config/hk_mdns

Edit /etc/config/firewall and look for the section “config zone ‘lan’“. Add a new line like below, to include wlan0 to the ‘lan‘ network:

config zone 'lan'

option name 'lan'
list network 'lan'
list network 'wlan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'

Again, inside /etc/config/network, make sure the eth1 will have its option proto set to ‘static’ and that its IP address configured to one from a private network different from the one you have on your WIFI network.

Reboot the bridge and remove the Ethernet cable.

You will now be able to connect to the WIFI interface via SSH but the Hue services won’t be running correctly.

The following network sockets exist right now:

If we connect the Ethernet cable the errors will dissapear and new sockets will be created(if the error persists reboot the bridge but keep the Ethernet cable connected):

I have checked every ASCII file on the system (or at least I think I did) and could not find any reference of eth1 anywhere.

I came to the conclusion that eth1 is hardcoded somewhere in the binaries.

Someone mentioned that editing /usr/sbin/ipbridge in hex and replacing the eth1 string with wlan0 will make things work. Unfortunately it did not work for me.

One solution I thought of, was to create an udev rule which would have renamed eth1 to wlan0 but udev is not available on OpenWRT. We have hotplug2 which didn’t help me in this situation.

So if the services expect eth1 to be up, but don’t care if the interface can reach the Internet or not let’s give them that 🙂

Take a RJ45 jack and create an Ethernet loopback. Pin 1 should be connected to Pin 3 and Pin 2 should be connected to Pin 6.

Plug that into the Ethernet port and you will be just fine:

eth1 Link encap:Ethernet HWaddr 00:17:88:4E:24:38
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fddf:d971:4229::1/60 Scope:Global
inet6 addr: fe80::217:88ff:fe4e:2438/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:916 (916.0 B) TX bytes:916 (916.0 B)
Interrupt:5

See how the RX bytes = TX bytes? That’s because of the loopback.

Now the Hue Bridge can be used on WIFI only 🙂

Conclusions:

This has been a good two days project for me. I’m amazed by how people actually hacked this.

At first pepe2k from OpenWRT forum figured out that we could remove a resistor which caused the u-boot sequence to drop us to the prompt. He also analyzed a dump of the the firmware, discovering that the root password is taken from the u-boot env variables.

After that, Colin O’Flynn discovered that we can bypass the access of the flash by using a wire between GND and the data out (DO) PIN of the chip.

References:

91 comments on Philips Hue 2.1 – Enabling WIFI

  1. This doesnt work for me unfortunately. When I try to execute wpa_supplicant, I get the error:

    root@Philips-hue:/usr/sbin# wpa_supplicant
    -ash: wpa_supplicant/: not found

    But with ls /usr/sbin I can see the wpa_supplicant file :/

    1. If you’re inside /usr/sbin execute like this:
      root@Philips-hue:/usr/sbin# ./wpa_supplicant

      Otherwise use the full path when executing files with the executable permission set:
      root@Philips-hue:/usr/sbin# /usr/sbin/wpa_supplicant

    1. Should work. Let me know with which firmware you’ll test. I’ve moved away from Hue hub to Deconz 🙂

  2. Its working :). But I have a very small problem with the iOS App iConnectHue. This app allows multiple Bridges at the same time (very useful). But now the App don’t recognize my bridge. First it find it but say I have a problem and after a while the bridge is offline for the app. I think the app find die bridge on my WiFi with IP 192.168.179.19 and then get the info from the bridge (LAN settings) and this IP differs 192.169.1.2 (According your instructions that eth0 IP has to be another IP outside my home IP range?).

    I have not problems with the Philips Hue App.

    1. Can you define, manually, the bridge IP address in iconnect app? I don’t think this is related to the ip address of the LAN, but yes, you need to set something outside your home ip range manually.

      1. Yes this is possible but not working. I set the IP to 192.168.178.19 and the App find the bridge. But after few seconds the app say “connection problems”. I think because the app get the info from the bridge that the IP is 192.168.1.2.

        1. Try this inside the console of the hue hub, should show connection attempts:
          logread -f

          1. With “logread -f” I see the incomming connection:

            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:24 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:29 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:29 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [http_server.c,368,State Ready …]
            Thu Sep 20 09:19:33 2018 daemon.notice ipbridge: [webserver.c,234,Accepting connections]

            But I see in my App that my manually entered IP: 192.168.178.19 will automatically changed to 192.168.1.2 after successful connection. And then the app seems to try to reconnect on the 1.2 IP … I looked closer to the official Philips Hue App and discovered that the app opens a remote connection instead of a local. On my other (not rooted) bridge the Hue app is local connected…..

          2. Yes, it initiates a remote connection to the Hue Cloud services.

          3. I really don’t know why. I changed nothing … but now the local connection works. VERY VERY strange.

  3. @Andrei BANARU
    I activated the WiFi for my 2. bridge and its working fine, too. A very very BIG THANK YOU for your effort and time!!!!!!!!!!

  4. The Wifi mod works even after few weeks very good. But the problems that the bridge is only available trough the remote access (online) is still there. The Hue App shows the connection status „remote access“ and after few seconds or minutes its connected via LAN. And then somewhile its again connected via online cloud.

    Do you have an idea why this happens? I have only limited knowledge in Linux …

  5. Hi

    Any idea what do do if I lost the original root user password hash? 😀

    Long story short, I copied the hash into a notepad but forgot to save it, put my pc to sleep and the next day I woke it up I had an unfortunate blue screen on Winblows…

    Without restoring the root hash to the original I am only able to control the HUE bridge locally on my LAN and not over the WAN as the bridge uses that hash to authenticate to the cloud API…

    Thanks,
    Pete

      1. Thanks Andrei.

        I did think about that, but then I wasn’t sure if it would cause any conflicts. 🙂

        Any1 willing to share theirs? 😀

        1. You can use mine:

          security=$5$2t8kNVLA5/ZNHf1Y$EBm33Vfk7NmBYYL79AD1WvBftu4LTO9JklSlDiDYZd/

  6. When I try to run wpa_supplicant I get a few errors printed out:

    root@Philipp:/usr/sbin# ./wpa_supplicant
    ./wpa_supplicant: line 1: ./debian-binary0000644000015300001570000000000412653442625014033: not found
    ./wpa_supplicant: line 2: 7$▒E▒: not found
    and so on…

    What to do now?

    1. What happens if you execute:
      /usr/sbin/wpad

      Please show the result of:
      cat /etc/*release

  7. Is there an easy way to bolt opkg back into the release ? would make life much easier…

  8. I chose a different approach. I edited /etc/init.d/network.

    I added:
    if [ ! -z “`/sbin/ifconfig -a | /bin/grep \”wlan0\”`” ] ; then
    ip link set eth1 name eth2
    ip link set wlan0 name eth1
    fi

    at the top of start_service.

    This renames the eth1 to eth2 and wlan0 to eth1. All errors disappear!

    Also, I didn’t install wpa_supplicant in the same way.

    I located the opkg version from openwrt that goes with the precise version of the package Philips used, extracted it manually and then used opkg to install wpa_supplicant. Worked a treat!
    This is because Philips didn’t *uninstall* opkg, but instead just deleted the executable and lib dirs. The package database was left intact!

    1. That’s awesome. I’ll try this on my own hub asap.
      Your solution should fix all the errors and there will be no need for that hardware loopback I’ve added.

      1. Did you have any success with this method? I used the “ip” package from OpenWRT, and while it successfully renames eth1 to eth2, wlan0 disappears and the “new” eth1 is the same as eth2 (at least it has the same MAC).

        I tried to shuffle the interfaces around manually while connected via UART, but to no avail. It looks like the device names are hardcoded elsewhere.

        I’m on firmware 1811120916.

    2. Hi Guys,

      Just wanted to add my two cents. This guide worked perfectly! – Thank you Andrei and Melanie for your input!

      To summarize my situation, the reason for me wanting WiFi connectivity, is because my ethernet port was damaged by a surge.

      So as you can imagine, I battled to get the wpad/wpa supplicant binary copied across to the device, since I didn’t have SSH access. What I did have, however, and it’s also center to this guide, was serial access.

      Long story short… with the help of virtual SSID’s I was able to get the device temporarily connected via WEP, then SSH and upload the proper binary, and continue my configuration.

      I would however like to add, once initial wireless-networking was up and running, the whole process was very quick.

      1. As per Melanie (in the comments), add

      “if [ ! -z “`/sbin/ifconfig -a | /bin/grep \”wlan0\”`” ] ; then
      ip link set eth1 name eth2
      ip link set wlan0 name eth1
      fi”

      without quotes to the network binary, right between { and init_switch.

      Also follow the guide diligently, it accurate, and will work for you.

      1. I managed to brick my own last night.

        Can one of you please share dd dumps of:
        /dev/mtd4-9 ?

        Thanks!

        1. First of all: Thanks a lot for this guide and the effort you put into it!!
          Have you meanwhile received a dump of /dev/mtd4-9 ?
          If not, please let me know if you still need it and I will pull one from my bridge this weekend.

          1. I haven’t received the dump but I don’t need it anymore. Thanks!

      2. I use this WIFI Hack now for few month and it almost work good. But few apps like iConnectHue have problems to conenct to my bridge. The official hue app works great. And now I saw the new fix:

        – I added the 4 lines to the etc/init.d/network file right after the {.
        – I restart my bridge and it works like before … but when I remove the loopback adapter it doesnt work anymore
        – problems with iConnectHue still exists

        So the fix makes no sense to me …. ?

        1. If I unplug the loopback adapter then logread -f will show this here:

          Thu Mar 28 09:39:33 2019 local7.err philipshueoben nginx: 2019/03/28 09:39:33 [error] 1377#0: *18 connect() failed (146: Unknown error) while connecting to upstream, client: 192.168.178.6, server: , request: “GET /api/2nFs7xmIrjHSA1DeU524YB1ojJq49hMEycVl0Pj3/config HTTP/1.1”, upstream: “http://127.0.0.1:9001/api/2nFs7xmIrjHSA1DeU524YB1ojJq49hMEycVl0Pj3/config”, host: “192.168.178.20”

          192.168.178.6 is my iPhone with Hue App that cannot connect anymore.
          192.168.178.20 is my hue (philipshueoben name)

          When I reinsert the loopback adapter everything is ok.

    3. Can you elaborate a bit on the process of installing/re-enabling opkg (how to find the correct version, manual extraction etc.). Thanks!

    4. Could you help me with doing the same install of opkg? I tried to copy files of another openwrt system over for opkg. but the /rom/bin directory gave me an error saying that it was read only and I couldn’t make it r/w

    5. could you possibly run explain how you went about installing opkg in more detail? I have been trying to do it and fail at every attempt. I would be very greatful!

  9. Hi, tried to root my bridge and after reading out the default pass I give the bridge a reset and now:

    47.070000] SQUASHFS error: Unable to read fragment cache entry [54781a]
    [ 47.080000] SQUASHFS error: Unable to read page, block 54781a, size 13298
    [ 47.470000] SQUASHFS error: xz decompression failed, data probably corrupt
    [ 47.480000] SQUASHFS error: squashfs_read_data failed to read block 0x3f613a
    [ 47.570000] SQUASHFS error: xz decompression failed, data probably corrupt
    [ 47.570000] SQUASHFS error: squashfs_read_data failed to read block 0x3f613a
    [ 48.980000] SQUASHFS error: xz decompression failed, data probably corrupt
    [ 48.980000] SQUASHFS error: squashfs_read_data failed to read block 0x571a3e

    Any Idea??

      1. Nö. Before. I Set These commands:

        setenv bootdelay 3
        saveenv
        reset

        Nothing more.

        I am able to setenv security and login to hue but errormessages keep going on. Then the bridge reboots

    1. For anyone who happens to see this, I experienced the same issue and was able to fix it by switching the bootslot.

      bootslot set valid 0
      bootslot set valid 1
      bootslot toggle active
      reboot now

      After that you should be good. Updating the bridge firmware in the Hue app appears to fix the other bootslot.

  10. Well,. I realized that there was not

    ** Device 0 not available

    Maybe a reason?!

  11. Hi,
    By any chance… did anyone got the JTAG working?
    I thought to add 0ohm resistors/jumpers where needed near the 14-pins header… but can’t find the right TMS/TCK/TDI/TDO… :/

  12. It’s been lots of fun messing with this little box.
    I enabled opkg as explained by Melanie (thx!) and meanwhile figured out a way to teach my dimmer switch some new tricks
    First spent almost a full night trying to capture traffic on /dev/ttyZigbee (/dev/ttyACM0).. until I came across the idea to parse logread -f output (https://github.com/Rocka84/pushing-hue)
    Since last weekend I am finally able to control my 15 year old squeezebox with the switch, pretty neat 🙂

    Next up: openvpn?

  13. After playing around with this, I’ll chip in. Important to note – I’m on firmware 1932073040.
    The root procedure is the same. However, the ip command is now missing from the system. I added it with opkg, and modified /etc/init.d/networking. However, something along the way renames the wireless eth1 back to wlan0, so that’s a no go. Also, why some 3rd party applications don’t work. If i query the server via a GET on /config, i see it’s reporting the address from the eth1 device, which at this point would be a bogus static address, and not the one on wlan0.

  14. Have you ever noticed any firmware files or URLs sitting around?

    Having these files would allow 3rd party zigbee implementations to upgrade the lamps.
    There’s some experiments being done over here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/270
    Getting the actual URLs (e.g. http://fds.dc1.philips.com/firmware/ZGB_100B_010C/16783872/100B-010C-01001A00-ConfLight-Lamps_0012.zigbee) is somewhat complicated and it seems noone has had success so far.

  15. have issues with the RSA key, i cannot create access trought SSH 🙁 only telnet, but need SSH to install the OPKG.
    I tried everthing i know but still have this error, can someone help ?

    error: not a valid rsa key file: key

  16. Im stuck at the ssh factory part.
    Im getting an error if i use puttykeygen or the other programs to generate a key. So i cannot use the SSH to install the WPA files.
    error: not a valid rsa key file: key

    can someone help?

  17. new here, I’m wondering how SW upgrade is being done.
    Would it be possible to redirect to one’s own server and install a modified image?

  18. I am at the step to enabling SSH but i have troubles, my knowledge is limited so i need a detailed explanations.

    I generate an RSA2048 key via puttygen and copy at clipboard the string and saved the Private Key
    When i enter Bridge via telnet and run the follow commands

    cd /
    sudo vi key
    shift+right click -> esc -> : -> wq -> enter

    after

    ssh-factory-key -r key

    i receive an error

    “error not valid rsa key…”

    Could anyone help me what i am doing wrong?

    1. I had to run
      dropbearkey -y -f key | grep ^ssh-rsa > key_public
      then I ran
      ssh-factory-key -r key_public

      Hope this helps

    2. Figure out. just make sure that all the letters and inserted
      In my ocasion the first letters
      ssh-rsa AAA***
      was entered as
      sh-rsa AAA***

      the “s” was missing

  19. Detailed instruktions for manual installation of opkg:
    https://github.com/Rocka84/pushing-hue/issues/1#issue-451827552

    I hav made some experiments with LuCI web interface.

    I run the following commands:
    mv /www/index.html /www/licenses.html (otherwise LuCI installation won’t be complete)
    opkg update
    opkg install luci

    The last row will install luci, uhttpd, lua, rpcd and som ubus libs. Everything will fit into avalable mem!

    LuCI will be installed in a single-user fashion though.
    Since the root password normally is unknown, you will need to enable support for additional accounts (with konown pwd)
    See https://forum.openwrt.org/t/solved-luci-add-support-user-in-addition-to-root/17402/3

    After a reboot you will be able to log on to LuCI (just enter the bridge ip in your browser)
    All LuCI features seem to be working fine including real time CPU workload graph.

    =======
    = BUT:
    =======

    The link between smartphone app and bridge will now be broken

    logread -f will show something like:
    Fri Feb 14 22:21:37 2020 user.info eventing[1374]: Sending request to 127.0.0.1:8083/v2_pre1/pub/api
    Fri Feb 14 22:21:37 2020 user.err eventing[1374]: Connection refused
    Fri Feb 14 22:21:37 2020 user.err eventing[1374]: Transport endpoint is not connected
    Fri Feb 14 22:21:37 2020 user.err eventing[1374]: Event publishing failed

    The reason for this is LuCI installs uhttpd webserver, wheras the hue system relies entirely upon nginx
    uhttpd hijacks requests intended for hue, hence the log entries above.

    Remedy:
    opkg remove uhttp*
    This will fix hue bridge, but instead LuCI will not work properly. (nginx is not configured for cgi)
    opkg remove luci* will get rid of the other packages

    If someone knows a way to make LuCI co-exist with hue/nginx, please share!

  20. It looks like that firmware 1938052050 doesn’t have mac80211.ko kernel module to prevent people from enabling wifi.
    Too bad.

  21. I have opkg and wpad installed and wpa_supplicant appears to work, however the device wlan0 does not seem to be installed? Any thoughts?
    Outputs are as below and I have updated to latest bridge firmware version 1938052050.

    Thanks!

    ***

    root@Philips-hue:/usr/sbin# iwconfig
    lo no wireless extensions.

    eth1 no wireless extensions.

    eth0 no wireless extensions.

    ***

    root@Philips-hue:/usr/sbin# iw wlan0 link
    nl80211 not found.

    ***

    root@Philips-hue:/# cat /etc/*release
    DISTRIB_ID=’OpenWrt’
    DISTRIB_RELEASE=’Chaos Calmer’
    DISTRIB_REVISION=’r46875′
    DISTRIB_CODENAME=’chaos_calmer’
    DISTRIB_TARGET=’ar71xx/generic’
    DISTRIB_DESCRIPTION=’OpenWrt Chaos Calmer 15.05.1′
    DISTRIB_TAINTS=’no-all busybox override’

  22. It seems like the latest firmware in June 2020 no longer has wifi support (no modules). I have tried to build an openwrt image with support, but no luck just yet. I have also just tried to build kernel modules for the current kernel (4.4.60), but I think maybe the kernel needs to be compiled with some additional symbols to make them work. Any chance you can provide the kernel image and the modules from a working version?

  23. Stupid question – after enabling SSH, you advise to restore the original root user password hash – I’m guessing I need to create *another* user then, to successfully use SSH?

  24. My Hue bridge is “2.X”, only eht0, eth1, lo interfaces in ifconfig / ls -l /sys/class/net/ – no wlan0. Has Philips somehow disabled the wlan0 interface or do I really not have one? 🙁

  25. Just tried this today and while I can get it to show the login prompt, I can’t get it to drop to a shell 🙁 When I go to bypass the flash during boot, I get the following:
    kernel panic-not syncing: VFS: unable to mount root fs on unknown block(0,0)

    No clue what firmware version it’s using unfortunately, this is a spare bridge I’ve had for a year or so.
    Any thoughts?

    1. Actually, get this–I was able to get it to drop directly to a root shell without grabbing the root account’s hash and changing the U-Boot parameters! During the boot process, I touched a wire from ground to a different solder point (the one just below SC98 in the image above). I was then able to set up public key auth for SSH.

  26. Tried the instruction, but I always get this – and nothing more, at boot – see below.
    Always ends-up with ‘Stack Pointer at: 80377f98’.
    Before that the brig is not reacting to board reset, etc. Only power ‘blue’ led is shining…

    Any advice what to do with this hue?

    U-Boot 1.1.4 (May 15 2017 – 14:25:28)

    bsb002 – Honey Bee 2.0DRAM:
    sri
    Honey Bee 2.0
    ath_ddr_initial_config(195): (16bit) ddr2 init
    ath_sys_frequency: cpu 650 ddr 597 ahb 216
    tap = 0x00000003
    Tap (low, high) = (0xaa55aa55, 0x0)
    Tap values = (0x8, 0x8, 0x8, 0x8)
    4 MB
    Top of RAM usable for U-Boot at: 80400000
    Reserving 216k for U-Boot at: 803c8000
    Reserving 192k for malloc() at: 80398000
    Reserving 44 Bytes for Board Info at: 80397fd4
    Reserving 36 Bytes for Global Data at: 80397fb0
    Reserving 128k for boot params() at: 80377fb0
    Stack Pointer at: 80377f98

    1. disconnect the bridge from the serial connection. power the bridge and then connect the serial connection.

  27. Tried the instruction, but I always get this – and nothing more, at boot – see below.
    Always ends-up with ‘Stack Pointer at: 80377f98’.
    Before that the bridge is not reacting to board reset, etc. Only power ‘blue’ led is shining…

    Any advice what to do with this hue?

    U-Boot 1.1.4 (May 15 2017 – 14:25:28)

    bsb002 – Honey Bee 2.0DRAM:
    sri
    Honey Bee 2.0
    ath_ddr_initial_config(195): (16bit) ddr2 init
    ath_sys_frequency: cpu 650 ddr 597 ahb 216
    tap = 0x00000003
    Tap (low, high) = (0xaa55aa55, 0x0)
    Tap values = (0x8, 0x8, 0x8, 0x8)
    4 MB
    Top of RAM usable for U-Boot at: 80400000
    Reserving 216k for U-Boot at: 803c8000
    Reserving 192k for malloc() at: 80398000
    Reserving 44 Bytes for Board Info at: 80397fd4
    Reserving 36 Bytes for Global Data at: 80397fb0
    Reserving 128k for boot params() at: 80377fb0
    Stack Pointer at: 80377f98

  28. For anyone who happens to see this, I experienced the same issue and was able to fix it by switching the bootslot.

    bootslot set valid 0
    bootslot set valid 1
    bootslot toggle active
    reboot now

    After that you should be good. Updating the bridge firmware in the Hue app appears to fix the other bootslot.

  29. Hello
    I have 2.1 bridge with software version 1943185030. When I run ifconfig i have only
    Link encap:Ethernet and Link encap:Local Loopback. Additionally I do not have /etc/config/wireless and /etc/config/hk_mdns. does that mean I can’t unblock wifi?

  30. I’d like to share another very interesting use case for rooting the hub:
    The device is using mosquitto for internal communication of state changes of attached zigbee devices. Which is a great chance to implement push updates from hub to other devices.
    I was able to use this to interface to home assistant, with my use case being dimmer switches so far.
    To anyone interested, I’m documenting my efforts below, feel free to join the party 🙂

    https://community.home-assistant.io/t/native-mqtt-push-updates-from-hue-hub/299504

    1. Hi Shub,

      Were you able to set up WiFi on later firmware versions in 2021? Or did you configure it prior to the later firmware that blocks access to wlan0?

      Thanks!

  31. I can’t seem to log into the shell, no matter what password hash I enter in u-boot. I tried the one from this article, I tried an MD5 hash ($1$3vGNd7Q3$ISqFeo1VkmQV6nyriUV0V/), I tried plenty of ones generated with mkpasswd but I only get ‘Login Incorrect’

    This is a brand new April 2021 bridge running 1.44.1944193080

  32. Alright, got SSH working. The “setenv security ‘$5$wbgtEC1iF$ugIfQUoE7SNg4mplDI/7xdfLC7jXoMAkupeMsm10hY9′” hash worked, but ONLY after I did an initial setup of the Hue bridge.

    In the latest 1944* firmware, there are no host keys for dropbear, so SSH is disabled by default. You need to generate an RSA and a DSS hostkey and reboot the bridge for SSH to be enabled:

    dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
    dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key
    reboot

  33. i can’t get wifi to work i get:

    root@Philips-hue:~# wifi
    root@Philips-hue:~# radio0(mac80211): Interface type not supported

  34. I’ve managed to compile ath9k.ko, mac80211.ko, etc. for the latest firmware, after days of struggling with qsdk cross-compiling. Unfortunately the system still doesn’t “see” the wi-fi device even after successfully insmod-ding the drivers (with no errors in dmesg). I’m trying to compile backported driver files (i.e. versions that include the latest improvements) but I’m running into build issues. I’ll share files/instructions if I manage to make it work.

  35. Hi, I recently got my hands on a V2.1 bridge that stayed off for quite an long time. It does not connect to LAN/internet.
    After I connect to serial port, I see in uboot :
    Device 0 not available and it drop me to ath prompt.
    I do not short the test point nor I’ve desoldered the resistor.
    Does anyone know if I can reflash the firmware via TFTP or somthing along that way.
    Many thanks
    Noar

  36. I’m starting to suspect Philips disabled the serial port with update 1947108030, released on October 18, 2021.

    A few weeks ago, I got a bricked bridge due to a faulty update. But through the serial port, by gaining access to uboot and fiddling with it (more specifically switching “bootslot” uboot environment variable (0 1)), I managed to fix it.

    However, recently, I tried again to access the serial port, without luck, it doesn’t look like it’s emitting data anymore after the 1947108030.

    But I might be wrong (faulty wiring on my part), so if anybody could it confirm or not if they have a working serial port with an up to date Bridge?

  37. #Kakwa Running 1948086000 I am still able to access the serial port.
    After rooting the bridge and making some edits, the bridge is stuck while updating the firmware though. By setting the bootslot to 0, I was able to to start it up, but it keeps dropping the network connection, watchdog keeps kicking in.
    If you have any idea how to solve it, please let me know.

  38. @Robbie – I just ran into the same problem after what I guess was a mandatory update after the recent log4j fiasco. I was still able to access the hub via the serial connection. One boot slot had no internet at all, the other had an unstable one. From the unstable one, I ran the factory reset script. After one reboot, the software successfully updated to 1.49.1949107040, and I did not lose my root access. The overlay file system gets wiped though, so I did lose my custom scripts and miscellaneous “hue jazz” modifications [see https://github.com/20goto10/hue-jazz), not to mention all the lights, rooms, and dimmer setup needed to be redone. Small price to pay vs. having a useless brick and no lights in the bathroom.

    I think the reset button on the bottom of the device would’ve accomplished the same thing (minus any ability to perform backups of customizations) but I can’t say for sure. I did it the hard way.

    1. Er, correction, I ran the reset script from the stable slot (but it probably doesn’t matter).

  39. I was able to retain my configuration (i.e. no factory reset) and root via ssh on my bridge over upgrade from 1.48 to 1.49. However, diagcd was repeatedly crashing for me on the new version. For now, stopped diagcd via init.d (/etc/init.d/diagcd stop) which stopped the diagcd-caused boot loop.
    Otherwise no issues observed with my setup on 1.49

    # cat /tmp/exitlog/diagcd.exit.0
    {“exitcode”:127,”runtime”:6,”timestamp”:”2021-12-14T14:33:32″}

    # logread -f
    Sat Jan 22 16:43:53 2022 daemon.info procd: Instance diagcd exit with error code 32512 after 0 seconds
    Sat Jan 22 16:43:53 2022 daemon.info procd: Instance diagcd::instance1 s in a crash loop 26 crashes, 0 seconds since last crash
    Sat Jan 22 16:43:53 2022 daemon.info procd: – shutdown –

  40. Manually running diagcd with config – I ASSUME – explains what kept it from doing its job on my device after upgrade to 1.49… customizations regarding (lib)curl:

    # /usr/bin/diagcd /etc/config/diagcd
    Error relocating /usr/lib/libcurl.so.4: fcntl64: symbol not found
    Error relocating /usr/lib/libcurl.so.4: __ctype_b: symbol not found

    Fix:

    Get opkg running again (binary, feed & config in here 1)
    Install libc from here using opkg
    opkg install curl
    profit

  41. After the latest update, the wifi stopped working.

    root@Philips-hue:~# cat /etc/swversion
    1938112040

    root@Philips-hue:~# wifi
    radio0(mac80211): Interface type not supported
    radio0(mac80211): Interface type not supported

    @Ben Chadwick did you manage to get the wifi working again?

    1. I never did get it to work and eventually gave up trying, but I still think it may be possible with the right reconfiguration of the underlying kernel config and some patching. I was able to build various necessary kernel modules and get them onto the Hue, but I never got them to successfully recognize the wi-fi. I never went so far as reflashing the kernel itself, since I didn’t want to risk bricking it (after all, I still need to turn my lights on and off).

  42. Thanks very much for this interesting write-up. I thought I’d give this ago, knowing that a subsequent bridge update could (and most likely would) either wipe out the changes or brick it (intentionally or accidentally).

    When I rooted my v2.1 (that was the trivial part), I got to a system which had no wireless tools, no wifi kernel module (neither loaded, nor present in /lib/modules/$(uname -r), no wpa_supplicant, etc. etc.

    In order to make it work, you’d need to either find or (cross-)compile the suitable binaries, modules, tools, etc. It would probably work until the next time Philips decides to roll out an OS image update. Oh, and your lighting setup would just stop working, since you started to rely on the hacked-in WiFi 🙂

    If they’re smart, it would only completely overwrite the mods you had made. If they’re not (or just asshats), they could intentionally brick the device.

    In other words, that’d just be an ongoing battle that just isn’t worth it if you have any other responsibilities in life.
    IMO, Philips having the HW support and intentionally disabling it, are just muppets.

    I wanted to do this not because I wanted to hack it but because I don’t want to run one ethernet cable just for this box to be where it can reach all lights/switches.

    I’d rather just stop using their bridge altogether or hook it up to something like RPI with wlan/ethernet bridge configured.

    I think it’s time to burn that bridge 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.