search

bren1818 / TCPFirmwareRestore

Connected By TCP - Greenwave Reality Bridge Firmware - for restoring/re-flashing
11 stars 6 forks source link

What next? #2

Open inahas opened 7 years ago

inahas commented 7 years ago

I guess this question is better in its own thread.

Downgrading to 2.0.47 opens up the bridge and restores the web server functionality (somehow- lots of the links and images appear broken), but apparently the iOS app will not communicate with it so I am unable pair any of my bulbs and manage them...

What am I missing here? Am I supposed to install an alternative patched firmware or what?

I have over 15 TCP bulbs, and my ultimate goal is to create an OpenHAB extension that allows me to control them with the rest of my smart devices. Maybe an Alexa plugin as well. So the downgrade seems to be a step forward, but I think I'm still missing the whole picture as far as the baseline firmware is concerned...

bren1818 commented 7 years ago

Awesome. - The iOS App should have continued to work, and in my experience, the bridge should have even kept track of the bulbs. Check to see if the bridge's IP is accessible. If you can't control it with the iOS App - does it work with my other project here: https://github.com/bren1818/TCPLightingWebInterface?

inahas commented 7 years ago

I see. I suspect then that I somehow reset it to factory state while rebooting and pressing the Sync button so many times, or caused its database to get into a corrupt state.

The unit IP is accessible. My router lists it and I can easily SSH into it using WinSCP or Putty from my PC, so I don't see a reason why the iOS app can't. How does it find it anyway? Does it scan the entire IP range or does it rely on a host name? Maybe that part is not working.

I am tempted to let it upgrade itself then downgrade again. Or perhaps use one of the patched firmwares out there. Have you tried any? I need to settle on a firmware before the expiration of the 14 days SimpleDNS trial :)

I definitely want to use your alternate UI if nothing but because it demonstrates how the REST API works which I will need for my future plans, but I want to make sure first the unit is functioning using stock firmware to eliminate another variable while debugging any issue. Edit: I just realized your project is not a replacement of the built in UI but rather an external UI that communicates via REST. This is indeed an excellent way to test if the hub is providing basic functionality. I will setup and test later today.

bren1818 commented 7 years ago

Hmm, I had at one point corrupted my bridge, to the point I thought it was completely toast, which is how this project came to be, borrowing largely from another. When that occurred, my bridge continued to boot loop, it would start up , I could ssh into it, but it would die and reboot shortly thereafter.

If you ssh in as root and execute the following: /etc/init.d/rcS

what happens?

Have a peak here: https://github.com/hypergolic/greeenwave_firmware/issues/1 older note I made haha

inahas commented 7 years ago

I get this: ~ # /etc/init.d/rcS

.-----.----.-----.-----.-----.--.--.--.---.-.--.--.-----. | | | -| -| | | | | | | | -| | || |__||||____|.|_/|| ||

.----.-----.---.-.| || |.--.--. | | -| || | | | | | || |____|._|||||__ | ||

Booting: Apollo3, Version: 2.0.47

And it keeps going on until I CTRL-C to stop it. What does that mean? Do I need to flash again with another image?

bren1818 commented 7 years ago

I believe so - I ran into the same issue with my bridge where it got into an unstable state. I think I (at that time) flashed the modified base image @hypergolic made. I'll have to look at my bridges tonight and try re-flashing them.

Cheers,

inahas commented 7 years ago

OK. I turned off the DNS blocking/rerouting and that allowed the bridge to upgrade itself back to 3.0.80. My iOS app connected and all my bulbs are still there so apparently that part of the flash is left alone during the firmware flashing.

I'm going to try the patched firmware made by @hypergolic and see what happens.

inahas commented 7 years ago

Same thing. Still can't reach it using the app and getting the same output as before:

~ # /etc/init.d/rcS

.-----.----.-----.-----.-----.--.--.--.---.-.--.--.-----. | | | -| -| | | | | | | | -| | || |__||||____|.|_/|| ||

.----.-----.---.-.| || |.--.--. | | -| || | | | | | || |____|._|||||__ | ||

Booting: Apollo3, Version: 3.0.39

Any ideas?

bren1818 commented 7 years ago

Yes you're correct, the flashing doesn't seem to erase the bulbs tied to the bridge. I was pleasantly surprised by that, but I suppose it makes sense. So your bridge re updated ok? I guess the greenwave servers are still up. I'm still perplexed by the unusual address you had to use.

You should document your steps and push it to the repo. I'll try the same steps on my bridge again and add it in. I want to streamline the doc a little bit, but by the time it gets working usually people never want to try it again haha.

On May 18, 2017 4:54 PM, "inahas" notifications@github.com wrote:

OK. I turned off the DNS blocking/rerouting and that allowed the bridge to upgrade itself to 3.0.80. My iOS app connected and all my bulbs are still there so apparently that part of the flash is left alone during the firmware flashing.

I'm going to try the patched firmware made by @hypergolic https://github.com/hypergolic and see what happens.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bren1818/TCPFirmwareRestore/issues/2#issuecomment-302530134, or mute the thread https://github.com/notifications/unsubscribe-auth/ACDCH6c24pXOPcVS_si6xkez2DNMd5IIks5r7Kg7gaJpZM4Newuu .

bren1818 commented 7 years ago

Try flashing the original firmware and let it auto update. It was what I needed to do to mine.

In my docs I provide a link to some of the stock binary files. Best of luck!

On May 18, 2017 4:56 PM, "inahas" notifications@github.com wrote:

Same thing. Still can't reach it using the app and getting the same output as before:

~ # /etc/init.d/rcS

.-----.----.-----.-----.-----.--.--.--.---.-.--.--.-----. | | *| -| -| | | | | | | | -| | || |||||*|.|/| | |

| __ .----.-----.---.-.| | | |.--.--. | | - *| || | | | | | || ||.||*| *|| | |*____|

Booting: Apollo3, Version: 3.0.39

  • Mounting proc filesystem: [FAILED]
  • Mounting sys filesystem: [FAILED]
  • Mounting tmpfs filesystem: [ OK ]
  • Starting syslogd: [ OK ]
  • Starting kernel logger: [ OK ]
  • Creating basic nodes: [ OK ]
  • Loading kernel modules: [ OK ]
  • Using netlink for hotplug events: [ OK ]
  • Starting udev daemon: [FAILED]
  • Populating /dev with existing devices: [ OK ]
  • Letting udev process events: [ OK ]
  • Mounting mediaconfig: [FAILED]
  • Formatting config partition: [FAILED]
  • Mounting mediaconfig: [FAILED]
  • Formatting config partition: [FAILED]
  • Mounting mediaconfig: [FAILED]
  • Formatting config partition: [FAILED]

Any ideas?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bren1818/TCPFirmwareRestore/issues/2#issuecomment-302538995, or mute the thread https://github.com/notifications/unsubscribe-auth/ACDCH0irmLx4yXxtPlU6h-Y-53f4DlgUks5r7LCBgaJpZM4Newuu .

inahas commented 7 years ago

I think the weird URL is a side effect introduced by my setup. I used a slightly different setup than the one you recommend. Instead of mucking with my main router which is used by the whole family, I hooked up an old router (as a client to the main router) to configure the custom DNS information. This allows me to continue to experiment without disrupting the internet for everyone in the house. When I want to update from the real world, I plug the tcp hub into the main router. When I want to use my own DNS server, I plug it into the old router. It's been working great except for the fact that it is showing these weird URLs. That's my guess anyway.

What do you mean by the original firmware? I am currently at @hypergolic 's modified firmware.

After flashing 2.0.74 I let it auto-update and it updated itself to 3.0.80. I checked and it seems full functionality is restored (app access & bulbs). I then downgraded to @hypergolic firmware and it is behaving the same as 2.0.74 did (no app, no bulbs).

inahas commented 7 years ago

While browsing the files on the bridge I found this file under /etc/resolv.conf (it is actually a symlink to /tmp/resolv.conf) it contains:

# Generated by dhcpcd from eth0, eth0:ra # /etc/resolv.conf.head can replace this line domain austin.rr.com nameserver 192.168.1.1 nameserver 2605:6000:101e:136:c256:27ff:fed1:a02 # /etc/resolv.conf.tail can replace this line

Which is probably what is causing the odd URLs. No idea how this file came to be though and why it is in the /tmp directory. It could be network information cached by the bridge to speed things up. I'm not a Linux guy (shrug).

bren1818 commented 7 years ago

I see what you did about the router. Smart move I was considering doing the same thing, but was to lazy to fish out my spare router.

Ok, so hypergolic's firmware simply makes it so that SSH is enabled, and the device isn't supposed to call home, not to say that it wont. You indicated you're on 3.0.80. At last bet, I thought they only went as high as 3.074. You could try flashing the stock 2.074 (non hypergolic), then manually to 3.039 which I think was the last version which has ssh enabled - You'd need to ensure that the bridge cant talk to outside world. some firmware files here: https://www.exploitee.rs/index.php/Greenwave_Reality_Bulbs

Two thoughts which spring to my mind re: not seeing the bulbs in the app is 1) the bridge is re-updating itself so not discoverable 2) the bridge is behind your other router which may not be reachable over wifi. If I recall - the application lets you type in an IP of the bridge if you need to, you could try hard coding it. On my router, I make the IPs static by Mac address so it makes things a bit earier.

Re the /etc/resolve is interesting, good find. I'm not a huge linux person either, especially micro embedded linux. Looks like you;ve got a pretty good handle on this stuff!

inahas commented 7 years ago

Good news! Downgrading to 3.0.39 was successful and I got app access and bulbs are there too. So it appears this is the magical firmware for me.

A quick clarification to your comment. I only plug the hub into the old router when I'm attemtping a downgrade. Otherwise, I plug it directly into the main router (where I turn off/on greenwavereality.com via parental controls settings). So it should be reachable by the app at that point.

By the way, running /etc/init.d/rcS for me still generates the same output (with errors and all) and in fact appears to crash the software. A reboot is needed afterwards. I think this is the initial bootstrap script and probably shouldn't be rerun when the hub is already up and running. So I wouldn't use that as an indicator of the health of the firmware.

Time to play some more with this.

bren1818 commented 7 years ago

That's fantastic, I'm glad to hear it! Now just make sure it doesn't go rogue and update itself again :) I let my devices re-upgrade and have been working on my other project sporadically to control them. Haven't put as much time into it as I'd like but that's life.

You may be right about the rcS call. That said, when my bridge got messed up, the machine would run that script and then reboot unless I shelled in fast enough and killed the process.

I'm happy to hear it's working for you, have fun!

hypergolic commented 7 years ago

Just wanted to pop in and say that I can confirm that my firmware has stability issues like you described, the bridge locked up after about a month powered up, I havent had much time lately or felt like doing much, but it seems you guys have fixed it, glad I could help you and I'll look into the fixes you posted and update mine :).

Good work!

bren1818 commented 7 years ago

@hypergolic - I think the bridges themselves have some issues, but its all good. As far as I can tell the 3.0.39 version works the best, but will auto update as soon as it phones home. This isn't so bad if you end up bricking the bridge as it will auto update and fix, but definitely a pain. I've simply left my bridge to update as my router was reset and firewall rules were lost, but my time/use of the bulbs has dwindled substantially. Its summer time right?! Thanks again for your original work - it got the ball rolling!