Esp-homekit-devices: Devices can't finish installation

Created on 2 May 2020  Â·  75Comments  Â·  Source: RavenSystem/esp-homekit-devices

Hi!

Is there any way to enter into setup mode if I set wrong I/O inputs in my json configuration?
I flashed device without disassemble (OTA) and this is too hard to disassemble it and solder wires to reflash it, I have a brick which connects to my wifi but this is not in setup mode.

HAA

Most helpful comment

Let's get coordinated a bit more.

If you have a device that doesn't update, take a log! use nc -kulnw0 45678 just like @blimpmason did.

Then the answer is obvious from the first few lines:

  • OTABOOT VERSION: 1.0.0 or OTAMAIN VERSION: 1.0.0 => This is LCM code. Wait till GitHub fixes the server (yes, we are finally communicating with them since a few days ago thanks to @tonysprenk). Or reflash if you cannot wait.
  • STARTING =>you are using HAA-OTA but it doesn't instantly show its version number. If you are lucky it gets to the line where it says compare. The number behind with is your current HAA-OTA version.

HAA-OTA is a stripped down clone from LCM which is different in three ways:

  • it can only support HAA whereas LCM supports any possible binary and the user code owner doesn't need a secret key to sign this code since GitHub will protect the authenticity.
  • because it only works for HAA, HAA-OTA dropped the certificate check on GitHub and you can get away with a spoofed server.
  • instead @RavenSystem signed his binaries which he can do because he only has to support HAA

LCM versions 2.0.0 and higher solved the block-out dilemma by making an emergency mode where a new signed OTABOOT file can be loaded from a local server. So depending if you want to ever switch away from HAA you can use HAA-OTA or LCM instead.

The essence of this issue 922 is that @RavenSystem doesn't always keep backward compatible binaries around. And since he is the only one with the secret key to sign the HAA or HAA-OTA, without his cooperation, this cannot be solved.
I leave it to others to comment if such backward compatible binaries are becoming available. I for one only use HAA on a few devices that I can easily reflash so have no full understanding of the different paths through esp-homekit-devices landscape... Just ran into a roadblock myself one day and @RavenSystem did fix it.

All 75 comments

Emergency setup mode:
Plug it.
Unplug after 1 second.
Plug it.
Device is in setup mode. Connect to it usong it IP address.

I tried many times. It disconnects from wifi and then connects to wifi. But still connection refused. What am I doing wrong? Firmware 2.1.1.

Maybe you unplug it too soon. Try with 2 seconds instead 1.

Or add it to HomeKit and turn on and off accessory 8 times quickly.

I don't know why, but I can't add it to homekit, the device isn't accessible.
But after switching on it gets IP address via DHCP and pingable.

The installation is unfinished.

Keep it connected for at least 15 minutes.

Hmmm. I was waiting for about an hour after initial flash.
(I was doing this with another devices and everything was ok, but this one (new type of device) – doesn't work).

Ok. Anyway I've got what do to. Thank you very much for your advices!

You can view HAA OTA installation logs using this: https://github.com/RavenSystem/esp-homekit-devices/wiki/Build-Instructions#haa-ota-logs

Wow. Interesting.

NEW CONNECTION LocalPort=dd9a DNS IP: 13.236.229.21 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
HTTP returns 404
Get file
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/3.0.2/main.bin HTTP/1.1
Host: github.com

Why 404?

It seems, there are no main.bin and main.bin.sig in 3.0.2

More logs

STARTING

Get version RavenSystem/haa_ota
NEW CONNECTION LocalPort=cfd5 DNS IP: 140.82.118.3 local..OK remote..OK SSL..OK set_fd to github.com port 443..Get version RavenSystem/haa_ota
NEW CONNECTION LocalPort=d08e DNS IP: 140.82.118.3 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK

GET /RavenSystem/haa_ota/releases/latest HTTP/1.1
Host: github.com

HTTP returns 302 for Current ROM is 0
Compare
3.0.2 with 2.2.3 = 1
RavenSystem/haa_ota@version:"3.0.2"
Current ROM is 0
Running BOOT
Get hash
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/3.0.2/main.bin.sig HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=cfd6 DNS IP: 140.82.118.3 local..OK remote..OK

GET /RavenSystem/haa_ota/releases/latest HTTP/1.1
Host: github.com

OK SSL..OK set_fd to github.com port 443..HTTP returns 302 for Current ROM is 0
Compare
3.0.2 with 2.2.3 = 1
RavenSystem/haa_ota@version:"3.0.2"
Current ROM is 0
Running BOOT
Get hash
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/3.0.2/main.bin.sig HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=d08f DNS IP: 140.82.118.3 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
HTTP returns 404
Get file
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/3.0.2/main.bin HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=cfd7 DNS IP: 140.82.118.3 local..OK remote..OK
sent OK
OK SSL..OK set_fd to github.com port 443..HTTP returns 404
Get file
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/3.0.2/main.bin HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=d090 DNS IP: 140.82.118.3 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
HTTP returns 404

I have also another devices which I flashed maybe two weeks ago, but never switched on, they can't install too with the same log.

It seems I was ok while HAA OTA v2.2.3 was latest. After HAA OTA v3.0.0 there are no main.bin and I can't finish install of my devices. Could you please be so kind and add main.bin/main.bin.sig there?

You are using an old haaboot.bin. Please, use last version for new installations.

Yes. I'll use for new installations new loader, but could you please place these files for me to upgrade existing devices which I can't reflash without disassemble?

Sorry, it is incompatible with current versions and it breaks new installations.

Ok. I'm trying to workaround this with fake server.
I placed files and made required redirects. Maybe you have idea why this error occurs?

Get version RavenSystem/haa_ota
NEW CONNECTION LocalPort=ce04 DNS IP: 10.0.0.2 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK

GET /RavenSystem/haa_ota/releases/latest HTTP/1.1
Host: github.com


HTTP returns 302 for Current ROM is 0
Compare
2.2.3 with 2.2.3 = 0
RavenSystem/haa_ota@version:"2.2.3"
Current ROM is 0
Running BOOT
Get hash
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/2.2.3/main.bin.sig HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=ce05 DNS IP: 10.0.0.2 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
HTTP returns 200
Get file
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/2.2.3/main.bin HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=ce06 DNS IP: 10.11.12.2 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
failed, return [-0x1]
wolfSSL_send error = -125

This error occurs because you are trying to do a MITM attack against an encrypted connection.

It checks certificate?

Help me to workaround this please, I have more than 20 bricked devices. :(

I have an idea. I just must make cert where cn=github.com

I hope it doesn’t check root certificates?

Doesn’t work.
Let me explain what am I doing.

I replaced github.com DNS with IP of my local server and placed files there.

I see it loads signature file properly, without errora, but it can’t load bin file. I think the issue isn’t in my ssl.

125 error in wolfssl doc means “out of buffer”. why? files are original, from your repository.

I reduced server side ssl buffers and now I don't have 125 error.
However I see in loop how it receives files. Why?

Get version RavenSystem/haa_ota
NEW CONNECTION LocalPort=c294 DNS IP: 10.0.0.2 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK

GET /RavenSystem/haa_ota/releases/latest HTTP/1.1
Host: github.com


HTTP returns 302 for Current ROM is 0
Compare
2.2.3 with 2.2.3 = 0
RavenSystem/haa_ota@version:"2.2.3"
Current ROM is 0
Running BOOT
Get hash
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/2.2.3/main.bin.sig HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=c295 DNS IP: 10.0.0.2 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
HTTP returns 200
Get file
DOWNLOADING
GET /RavenSystem/haa_ota/releases/download/2.2.3/main.bin HTTP/1.1
Host: github.com

NEW CONNECTION LocalPort=c296 DNS IP: 10.0.0.2 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
sent OK
HTTP returns 200

Nothing else in logs.

10.0.0.237 - - [03/May/2020:15:46:08 +0300] "GET /RavenSystem/haa_ota/releases/download/2.2.3/main.bin HTTP/1.1" 200 45822 "-" "-" "-"
10.0.0.37 - - [03/May/2020:15:46:09 +0300] "GET /RavenSystem/haa_ota/releases/download/2.2.3/main.bin HTTP/1.1" 200 411648 "-" "curl/7.64.1" "-"

when I download file (curl), I see full length of file – 411648.
Device receives only 45822 bytes. Is this normal?

Ok, thank you for your all advices.

I added a transition firmware to allow old haaboot to work. Try again.

Thank you very much. Your solution works perfectly. My device successfully upgraded into haa 2.1.2 and haa_ota 3.0.2. How long this will be available? I mean, when you'll make a new release, will it be supported or until next release only?

I had the exact same problem, flashed some Gosund WP5 outlets with HAA using Tuya-Convert, devices went into setup mode the first time and then connected to wifi but no setup mode the second time and not visible in HomeKit and they were unresponsive and seemed bricked, until last night when I tried again and it magically started updating them when looking at the logs with the nc command. Thanks a lot @RavenSystem for fixing it, I think many other people had the same issue recently, I was about to trash them and buy new ones...

@RavenSystem could you please answer my question? How long this transition firmware will be available?

We faced same main.bin thing in another issue.
Here is developer’s answer so far:
https://github.com/RavenSystem/esp-homekit-devices/issues/683#issuecomment-623256639

I may be having a similar issue — I flashed this Monoprice/Tuya Stitch smart outlet using tuya-convert with this thirdparty.bin as posted in this issue comment thread: https://github.com/ct-Open-Source/tuya-convert/issues/389#issuecomment-554106217.

The flash was successful and I was able to connect to the device at its SSID (LCM-XXXXXX) and set the wifi details per the instructions.

But I am never able to add the device in the iOS Home app — I've tried many times and it always times out.

I tried monitoring the logs via nc -kulnw0 45678 and after unplugging/replugging, I just get a variations on this over and over again:

user-init-done
wifiready-done
--- ota_boot...0
OTABOOT VERSION: 1.0.0
--- ota_init
userbeta='0' otabeta='0'
active_sector: 0x0
--- ota_set_verify...OFF
--- DNS: done!
--- ota_get_version
--- ota_connect LocalPort=fd5e DNS IP:192.30.255.112 local..OK remote..OK SSL..OK set_fd to github.com port 443..OK
GET /HomeACcessoryKid/life-cycle-manager/releases/latest HTTP/1.1
Host: github.com

Is there any hope for the device? I am unable to get it into setup mode or browse to its IP address, though I do see it has an IP address via my router admin (matching the MAC address).

@blimpmason where did you find the link to thirdparty.bin? It has old firmware that is broken and should be removed. I’m sorry to say that the only way to get your device working now is by flashing it by wire.

@tonysprenk thanks a lot for your response! That's what I was afraid of. The thirdparty.bin I used is actually the one you posted over in this tuya-convert issue thread: https://github.com/ct-Open-Source/tuya-convert/issues/389#issuecomment-554106217

It's also linked to in this guide: https://homekit.blog/forum/flashing-tuya-devices-supported-native-with-homekit-no-need-for-bridge/

I don't have the ambition to open it up and attempt a manual flash — could I donate it to you or @RavenSystem for testing/reflashing (if either of you are in a country with US 120V outlets)? Happy to ship the smart plug if it would be useful to help others flash these devices in the future.

Hi @blimpmason,

I’m sorry that a file I made has bricked your device. I thought I had deleted all reference to the file. I have deleted the comment and asked the website to delete the blog post. Thanks for bringing it to my attention.

I have no use for a 120v device as I live in Europe. I think it’s the same for @RavenSystem. In any case we know what’s wrong with the firmware so don’t need the device for that purpose anyway.

If you want to flash another device with esp-HomeKit-devices the latest release can be found here.

Again sorry for your loss (😉).

If GitHub reverts headers changes, it will work.

@RavenSystem when I tried to recover my device, I made fake “github” local server which just redirects to real github. As HAA_OTA don’t check root CA, it worked. I think this resolvable the same way. If people needs it, I can flash old firmware, test and write manual how to do this.

@nikbyte Yes! Please share how you did it! It would save a lot of hassle!

@tonysprenk what exact version of firmware must I flash to test this?

@tonysprenk no worries at all! I knew the risks going in and obviously didn't do all the homework I should have. I take full responsibility.

@RavenSystem @nikbyte so there might be hope for me to recover my device OTA?

Anything before February 29. I believe this is the latest broken HAA OTA.

@tonysprenk if I get files from this comment, this is what we need?
https://github.com/ct-Open-Source/tuya-convert/issues/389#issuecomment-553721234

@nikbyte here's the exact thirdparty.bin I used:
thirdparty.bin.zip

I deleted that comment to prevent people from bricking their devices. Found a backup. Can you send me a private message on discord so I can get it to you?

Discord @tsprenk

@tonysprenk But I still see comment from the link above and can download the files.
I'll try with .bin from @blimpmason

Ah i see. Yes it’s the same.

@tonysprenk @blimpmason help me, I never used so old firmware.
What I must set in OTA repository and OTA binary fields? Must I enable using of pre-releases?
By default there is "HomeACcessoryKid/ota-demo" and "main.bin".

@nikbyte I'm afraid I can't help — I didn't package the .bin myself, I just flashed it OTA using tuya-convert.

Ota repository is “RavenSystem/haa” Ota binary stays main.bin. But it won’t install because it cannot connect to the server due to header capitalization issue.

I guess don’t enable prerelease.

yes, @tonysprenk, I understand the issue. I think my method will help, but let me test and report here.

looking on that old OTA, I appreciate more and more @RavenSystem 's work.

Thanks for looking into it @nikbyte. And yes you are right without @RavenSystem our lives would be a lot less simple...

I’m afk now. If you have anymore questions I’m glad to help again in the morning. Thanks again!

@blimpmason, I tested your .bin. You flashed https://github.com/HomeACcessoryKid/life-cycle-manager of version 1.0.0 . It checks ssl certificate of github and my method doesn't work to spoil it. I think only way is to solder and reflash your device by wire. Or... wait for a miracle when github.com change "location" header into "Location" because old firmwares were sensitive to register of this header and when github did this, all old firmwares lost possibility to download updates.

@nikbyte, thanks so much for taking the time to test that .bin! I'll hold onto the device in case I feel inspired to solder / flash by wire. If I did want to go that route, which instructions would you recommend?

@nikbyte when did you encounter your update issue? Was it with firmware from before 29th of February? Could you share your fake server method so I can try on some of my devices that won’t update?

Guys, please share your findings on the solution of using a local github server.

I also have a few smart bulbs which cannot open to sold wires.

Any idea if that works idea will work on devices running older version of LCM instead of HAA OTA?

It will not work with devices running LCM. But we are still in talks with github support.

It will not work with devices running LCM. But we are still in talks with github support.

I hope you have a good outcome. The last update they sent you , it seemed like they didn’t even acknowledge that their server used to send “location” header for months before they switch to “Location”

Let's get coordinated a bit more.

If you have a device that doesn't update, take a log! use nc -kulnw0 45678 just like @blimpmason did.

Then the answer is obvious from the first few lines:

  • OTABOOT VERSION: 1.0.0 or OTAMAIN VERSION: 1.0.0 => This is LCM code. Wait till GitHub fixes the server (yes, we are finally communicating with them since a few days ago thanks to @tonysprenk). Or reflash if you cannot wait.
  • STARTING =>you are using HAA-OTA but it doesn't instantly show its version number. If you are lucky it gets to the line where it says compare. The number behind with is your current HAA-OTA version.

HAA-OTA is a stripped down clone from LCM which is different in three ways:

  • it can only support HAA whereas LCM supports any possible binary and the user code owner doesn't need a secret key to sign this code since GitHub will protect the authenticity.
  • because it only works for HAA, HAA-OTA dropped the certificate check on GitHub and you can get away with a spoofed server.
  • instead @RavenSystem signed his binaries which he can do because he only has to support HAA

LCM versions 2.0.0 and higher solved the block-out dilemma by making an emergency mode where a new signed OTABOOT file can be loaded from a local server. So depending if you want to ever switch away from HAA you can use HAA-OTA or LCM instead.

The essence of this issue 922 is that @RavenSystem doesn't always keep backward compatible binaries around. And since he is the only one with the secret key to sign the HAA or HAA-OTA, without his cooperation, this cannot be solved.
I leave it to others to comment if such backward compatible binaries are becoming available. I for one only use HAA on a few devices that I can easily reflash so have no full understanding of the different paths through esp-homekit-devices landscape... Just ran into a roadblock myself one day and @RavenSystem did fix it.

@tonysprenk
so, here is the solution for old HAA OTA, not LCM.

  1. You need some linux machine. It can be virtual machine, or Raspberry PI. Let its IP 10.0.0.2.
  2. On that server you need two services:
  3. dnsmasq
  4. nginx
  5. In DHCP settings in your router you need to set DNS server as 10.0.0.2

HAA-OTA will connect to that spoofed github server and get updates directly from github. There is no security issue because all binaries are signed.

dnsmasq settings

my dnsmasq.conf:

user=dnsmasq
group=dnsmasq

address=/github.com/10.0.0.2

nginx settings

you need to setup nginx using any manual from Internet where nginx uses ssl and self generated ssl certificate. when generate ssl certificate, set CN as github.com.

In nginx configuration you must remove all location and add own:

        location / {
            proxy_pass https://github.com/;
            proxy_hide_header Location;
            add_header Location $upstream_http_location;
        }

Last two lines above fix location header.

Then you're running nc and check that your devices go to this fake server, receive redirect and then upgrading usual way.

@RavenSystem has confirmed that he will reinstate the file needed to update the devices if/when github reverses the change.

@nikbyte Thanks for the write up on making the fake server. Unfortunately I only have devices running LCM so it did not work for me. But I have been thinking about a solution for the LCM devices. Would it be possible to use the rewrite feature in Charles Proxy to rewrite the header from location: to Location: ?

Unfortunately no. LCM is too smart. It verifies certificate of github and wouldn't work with any fake server.

That's what I thought. Thanks!

Fixed.

@nikbyte its not even possible with a ssl or https proxy? Really the only thing it’s doing is changing the location header everything else just gets passed through...

Headers are encrypted, and you can not modify them using a fake GitHub cert.

@tonysprenk not possible because proxy will use own certificate which is wrong when checked.

Ok thanks for clarifying. Let’s hope github support comes through. 🙏

@tonysprenk will you post on this thread if the github support comes through for us, or is there another issue I should be following for updates on that?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

noobydp picture noobydp  Â·  5Comments

maciekfreak picture maciekfreak  Â·  4Comments

lizzus picture lizzus  Â·  5Comments

xrust83 picture xrust83  Â·  4Comments

fluppie picture fluppie  Â·  5Comments