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 Order | Hue Bridge PIN Mapping | USB to TTL Mapping |
|---|---|---|
| 1 | GND | GND |
| 2 | NOT USED | |
| 3 | NOT USED | |
| 4 | RX | TX |
| 5 | TX | RX |
| 6 | NOT 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:
- Getting Root on Philips Hue Bridge 2.0
- Enabling the hidden Wi-Fi radio on the Philips Hue Bridge 2.0: Adventures with 802.11n, ZigBee 802.15.4 and OpenWrt
- HUE HACK: Soft Link Button
- Philips Hue Bridge v2 hacked (root access)
- “Jailbreaking” the V2 hub
- Experiments with enabling the built-in Wi-Fi radio hardware on the Philips Hue Bridge 2.0
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 :/
If you’re inside /usr/sbin execute like this:
root@Philips-hue:/usr/sbin# ./wpa_supplicantOtherwise use the full path when executing files with the executable permission set:
root@Philips-hue:/usr/sbin# /usr/sbin/wpa_supplicantDoes it still work?
Should work. Let me know with which firmware you’ll test. I’ve moved away from Hue hub to Deconz 🙂
I will test it with actual firmware: 1808300701
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.
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.
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.
Try this inside the console of the hue hub, should show connection attempts:
logread -fWith “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…..
Yes, it initiates a remote connection to the Hue Cloud services.
I really don’t know why. I changed nothing … but now the local connection works. VERY VERY strange.
@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!!!!!!!!!!
You’re welcome.
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 …
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
Should work with any hash from another user 🙂
Thanks Andrei.
I did think about that, but then I wasn’t sure if it would cause any conflicts. 🙂
Any1 willing to share theirs? 😀
You can use mine:
security=$5$2t8kNVLA5/ZNHf1Y$EBm33Vfk7NmBYYL79AD1WvBftu4LTO9JklSlDiDYZd/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?
What happens if you execute:
/usr/sbin/wpadPlease show the result of:
cat /etc/*releaseIs there an easy way to bolt opkg back into the release ? would make life much easier…
No idea. Probably more steps compared to just the wpa package.
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!
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.
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.
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.
I managed to brick my own last night.
Can one of you please share dd dumps of:
/dev/mtd4-9 ?
Thanks!
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.
I haven’t received the dump but I don’t need it anymore. Thanks!
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 …. ?
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.
Can you elaborate a bit on the process of installing/re-enabling opkg (how to find the correct version, manual extraction etc.). Thanks!
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
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!
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??
When did this happen? After setenv security?
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
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.
Well,. I realized that there was not
** Device 0 not available
Maybe a reason?!
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… :/
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?
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.
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.
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
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?
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?
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?
having same issue
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
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
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!
It looks like that firmware 1938052050 doesn’t have mac80211.ko kernel module to prevent people from enabling wifi.
Too bad.
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’
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?
I don’t suppose you’ve had any luck in this?
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?
disregard previous comment. figured out private key auth
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? 🙁
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?
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.
Anyone willing to share older files before the June 2020 wlan drop?
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
disconnect the bridge from the serial connection. power the bridge and then connect the serial connection.
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
I had same problem. Buy FT232RL and set it up to 3.3V
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.
curl has been crippled on one of the latest releases.(noticed it after upgrading to 1943082030)
Did some troubleshooting since I need curl for a custom script I’m running on the bridge.
Got it working again by reinstalling libcurl from here:
https://archive.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/packages/base/libcurl_7.40.0-3_ar71xx.ipk
Maybe this can help someone else with the same issue 🙂
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?
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
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!
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
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
i can’t get wifi to work i get:
root@Philips-hue:~# wifi
root@Philips-hue:~# radio0(mac80211): Interface type not supported
I am also running into this issue. Did you find a solution?
Have you figured it out?
Have the same issues as Filip, any1 find a solution?
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.
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
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?
#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.
@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.
Er, correction, I ran the reset script from the stable slot (but it probably doesn’t matter).
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 –
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
Anyone selling an already enabled wifi philips Hue? I am willing to buy it!
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?
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).
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 😉