Getting `"error": 404` and FinalStage SSID Never Comes

[CoderBlue]

I'm using a sonoff basic. When I get to step #4, when I'm supposed to connect to FinalStage SSID, FinalStage never comes. The firmware never seems to flash since I am able to continue to use the switch to turn on/off the outlet and I can repeat the first few steps starting the ITEAD server and connecting, etc. Anybody have this problem and any suggestions ? Using the latest commit. Thanks.

[gdgeist]

Piling on - two brand new SONOFF BASICS - no Final Stage SSID....attempted from Debian, Win 10, OSX - all three same results and symptoms as above.

[czyz]

I'm assuming the new firmware is from the factory and is thus only hitting those of us with newly-purchased Sonoff devices. Mine were purchased from Banggood in late August.

[andyfitter]

I guess there's probably still old stock coming through too, but as they don't have any issues and it Flashes with no problems, and we never hear of them via this thread. It's only the ones that have problems that end up here. Have the firmware version numbers changed, or is it something they've slipped in without updating the version?

[donoo]

Hello , I was able to flash my sonoff. I used my mobile phone Personal HotSpot to do this. When i used my Home Router, sonoff was not connecting and when it did couple of times, I was not able to see final stage ssid.

When i flashed my sonoff basic using my mobile phone hot spot I was able to flash it. After that i flashed another one using hotspot in single run. , I also changed params :[]. But I m not sure if this had any effect.

My sonoff basic version was 1.5.5 Windows 10. Hotspot phone i used windows mobile 10, 950 xl.

Hope this helps.

[czyz]

Hmm, unfortunately I can't make my phone a hotspot since my AT&T plan doesn't support "tethering" and if I were to enable that switch they'd switch me to a more expensive plan and I'd lose my grandfathered-in unlimited data. But I suspect that's not the problem I'm running into. My sonoff is connecting to my home network just fine, so the first part of the script is working with it, it's just that "timers" part (and anything else new that we won't see until jumping that hurdle) that's getting in the way.

"changed params:[]"?

[thefathefa]

I'm the exact same as @czyz : My Sonoff POW received one week ago connects to my home network fine, works fine with the ewelink app and when I try SonOTA, the first part of the script works fine as well. I am stuck not getting the FinalSSID...

Sonoff POW current version (after upgrade via ewelink) : 2.0.4 I think it was at version 2.0.2 when I unpacked it...

[thefathefa]

And just in case there would be some useful information in my traces, here are they are. I tried this case using my phone as AP since some people said it helped, but I have the same when I connect to my home router.

root@Surface4:~/SonOTA# ./sonota.py
Select IP address of the WiFi interface:
    0: 192.168.43.11
    1: 169.254.56.245
    2: 169.254.178.203
Select IP address [0]: 0
WiFi SSID: xxxxxxxx
WiFi Password: yyyyyyy

Using the following configuration:
        Server IP Address: 192.168.43.11
        WiFi SSID: xxxxxxxx
        WiFi Password: yyyyyyy
** Now connect via WiFi to your Sonoff device.
** Please change into the ITEAD WiFi network (ITEAD-100001XXXX). The default password is 12345678.
To reset the Sonoff to defaults, press the button for 7 seconds and the light will start flashing rapidly.
** This application should be kept running and will wait until connected to the Sonoff...
........................................~~ Connection attempt
>> HTTP GET /10.10.7.1/device
<< {
    "apikey": "55e5b6d8-ba95-46ec-b11d-1483d02af8b8",
    "deviceid": "10000b86fd",
    "accept": "post"
}
>> HTTP POST /10.10.7.1/ap
>> %s {
    "port": 8443,
    "serverName": "192.168.43.11",
    "ssid": "xxxxxxxx",
    "password": "yyyyyyy",
    "version": 4
}
<< {
    "error": 0
}
~~ Provisioning completed
Starting stage2...
** The IP address of <serve_host> (192.168.43.11) is not  assigned to any interface on this machine.
** Please change WiFi network to FrancoisAP and make sure 192.168.43.11 is being assigned to your WiFi interface.
** This application should be kept running and will wait until connected to the WiFi...
..............~~ Starting web server (HTTP port: 8080, HTTPS port 8443)
~~ Waiting for device to connect

*** IMPORTANT! ***
** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
This server should automatically be allocated the IP address: 192.168.4.2.
If you have successfully connected to "FinalStage" and this is not the IP Address you were allocated, please ensure no other device has connected, and reboot your Sonoff.
..........

*** IMPORTANT! ***
** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
This server should automatically be allocated the IP address: 192.168.4.2.
If you have successfully connected to "FinalStage" and this is not the IP Address you were allocated, please ensure no other device has connected, and reboot your Sonoff.
..........

[andyfitter]

I just tried with both my phone as an AP and also a MiFi device too, still the same 404. Should we trying to collect/correlate firmware version numbers?

[czyz]

I'm not sure where to grab the firmware version number. From the output of SonOTA I'd posted, I see these possibly-relevant lines:

    "version": 2,
    "romVersion": "1.5.2",
    "model": "PSA-B01-GL",

as well as

        "switch": "on",
        "fwVersion": "1.5.2",

So I guess I'm running version 1.5.2. Not sure what ""version": 2," means.

[sillyfrog]

See here for known firmware numbers that work: https://github.com/mirko/SonOTA/wiki

It's important to note that the latest firmware version is different depending on the device (ie: v1.5.5 maybe the latest on the Basic, but it's v1.1.0 on the Dual - when I have tested I tried with the shipped version and the latest version at the time).

Unfortunately that does not appear to be the problem as I have had success where others have not. I think there is some sort of internal race condition where it starts the upgrade before it makes the requests for the timers vs when it requests an update to the timers before the update starts. I have never had the 404 issue so have not been able to try and fix it.

My current ideas for something to try are (in this order):

1. Try changing the output given to the query (line 170) as per @czyz found.
2. Try changing it to a "no-op" (ie: never do a self.write_message) - it may hang, or it could go and do the update
3. Try sending the same upgrade response as is done on line 275

As mentioned, I'm not sure if this will work, but it's at least something to try, and if it does, I'm open to PR's :)

[andyfitter]

I’ve got a Sonoff dual and two Sonoff T1’s that are all failing in the same way. I’ve not touched python before but if I get some spare time today I may have a dig around and see if I can help.

[davorf]

Hello!

Last night I've tried Sonoff basic switch, but encountered the same problem (error 404, FinalStage AP never shows up). I've used Python 3.6.2 on Windows 10, and tried with, both router and mobile AP connection, but without success. I haven't checked firmware version on a device, but I'm going to try to update it via EWeLink app and see if that helps. I also have 3 Sonoff touch devices, and I'm going to try to flash them with this method, and see if it will work with them.

Best regards, Davor

[andyfitter]

Regarding the previous comment "If something is failing with the flash, you need to get the serial output from the device, E2A prints a lot of debug information to the console while trying to flash.". If I were to get a device thats failing, and attach the 4 pins to my Serial/USB adaptor, as if I were doing a normal 'hardware' flash, and view the output via a terminal, would I get the expected debug output?

If so, I'll get soldering.

[andyfitter]

Hmmm. Connected a serial port but not seeing anything of any value. Set the recommended parameters but see garbage at best. I still wonder if this is relevant. https://github.com/arendst/Sonoff-Tasmota/issues/639 Lots of people are saying that they cant 'hardware' Flash newer devices either, as we talked about higher up in this thread as the Flash mode of newer devices is different - DIO vs DOUT

[czyz]

The relevant portion of that page seems to be:

changing the board flash mode to DOUT works every time

Maybe that's it? Now to find out what "DOUT" is…

[thefathefa]

@czyz : if i'm not mistaken, we should already have access to DOUT flashing mode with the package we are using. See this here : https://github.com/arendst/Sonoff-Tasmota/issues/598 @sillyfrog, do you confirm?

[andyfitter]

Further to my serial port explorations earlier, I think I'm seeing the 4 byte pattern outlined here http://support.iteadstudio.com/support/discussions/topics/11000006870/page/1?url_locale= when I press the button, however, that is all I ever see, no visible/readable text at any other time. Do I need to issue some command to make it send more debug info?

[andyfitter]

Digging around inside the source of ExpressIf2Arduino it seems to only know about QIO and DIO Flash modes, and not DOUT. Could this be our problem? Even if the final target Image is built with DOUT, if the intermediate images are not, I'm guessing it might fail?

Could it be as simple(?) as rebuilding/repackaging the 'user2' image with a Flash mode of DOUT instead of QIO?

[khcnz]

Yes - this is possible - I have tested this approach - in a local branch I have actually removed the QUI/DIO code that decides what the URL is and always uses DIO

[sillyfrog]

I'm still not sure if this is 1 or 2 issues (ie: the 404 and not doing the full download), but it does look likely related (I have updated the issue title to reflect the 404).

I have included notes as to how I did the binary build (I used QIO) committed at: https://github.com/mirko/SonOTA/tree/master/static . This also links to the source of what I have built, you'll notice that although they are still separate constants, it actually uses the same URL in both cases.

That said, it's never actually running this code as it has not downloaded and installed the binary, it's the actual download that's dying. The line that has the first portion of the download is:

2017-09-29 21:49:41,201 (INFO) 200 GET /ota/image_user2-0x81000.bin?deviceid=10000a751c&ts=1486937972&sign=a2a3dd4d824537b5215a6df07845903811cdca95d84454d4fc625076d8b16b47 (10.0.1.148) 419.12ms

at https://github.com/mirko/SonOTA/issues/21#issuecomment-333249436

An example of what you would expect to see is: https://github.com/mirko/SonOTA/issues/21#issuecomment-331705770

(note the image_user2-0x81000.bin lines over and over as it gets each chunk.)

Doing a build with a different flash mode would be worth giving a go and dropping in place. I'm not across exactly how all of this works to know if it would help, but given other conversations about issues with the flash type, it can't be any worse! :)

The trick then will be to try and figure out if we can calculate the required flash mode (so it's more automated, it may end up as if we get a 404, try the other URL).

So I can test this further, is anyone based in Australia - I could buy/exchange a Basic from you or something?

[khcnz]

Well the problem is that the Espressif upgrade loader may be reading the first few bytes in that first package, realizes the flash mode bit is wrong and giving up. Would definitely recommend removing the code that tries to determine the flash mode and url (or setting both urls to the same) and send it an E2A build built using DOUT.

[andyfitter]

RE: The 'timers' query from the device, we were discussing previously. I wonder if this is a false lead... This link http://blog.nanl.de/2017/05/sonota-flashing-itead-sonoff-devices-via-original-ota-mechanism/ seems to imply that replying with an empty params list (as we do) is a valid response?

[sillyfrog]

I had missed the GET /ota/image_user2-0x81000.bin line, and I agree - totally worth giving a go with the DIO mode. I'll see if I can build something and upload in a branch for someone to test.

[sillyfrog]

I have done this (built it using DIO rather than QIO), and unfortunately it creates an identical .elf file (which is what esptool.py takes), so the resulting .bin file from esptool.py is the same :(

(The .bin file that Arduino makes is different, but not really of any value here).

(And the same with QOUT and DOUT)

[thefathefa]

@sillyfrog I'm not in Australia but I am willing to support. Please reach out via email and we'll find a way. My email is githubusername @ gmail. On top of a basic I could also arrange for a POW since this is what I use ;-)

[08-15at]

@sillyfrog did you add --flash_mode=dout to esptool.py, and does this result in different binaries ? cannot try now, as I'm not at home

[czyz]

I'm not in Australia but could mail that s20_us in that general direction. Though I suspect y'all might figure out the issue before it'd arrive.

[sillyfrog]

@thefathefa @czyz Thanks! I'll drop you a note if there is no one is Aus.

@08-15at Duh! I didn't look at the help for the command - thanks! I have now pushed a branch (DIO-mode) that has both image_user* files generated with DIO mode. If someone can please let me know if this works or not. The image_arduino.bin image is still the same, built with DOUT in the Arduino IDE.

Annoyingly I have not kept a backup of the original firmware, so I can't test other modes with the hardware that does work (I'm not sure you can restore it, best I can tell it's not worked for others, so maybe a mute point).

[andyfitter]

Shouldn’t we be aiming for DOUT mode not DIO?

On 4 Oct 2017, at 10:33 pm, sillyfrog notifications@github.com wrote:

@thefathefa @czyz Thanks! I'll drop you a note if there is no one is Aus.

@08-15at Duh! I didn't look at the help for the command - thanks! I have now pushed a branch (DIO-mode) that has both image_user* files generated with DIO mode. If someone can please let me know if this works or not. The image_arduino.bin image is still the same, built with DOUT in the Arduino IDE.

Annoyingly I have not kept a backup of the original firmware, so I can't test other modes with the hardware that does work (I'm not sure you can restore it, best I can tell it's not worked for others, so maybe a mute point).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[sillyfrog]

@andyfitter Maybe? I have not yet taken the time to properly understand this and the implications during the upgrade phase. Given it works for Sonoff-Tasmota (I think, there is discussion that it may not for the newer hardware), it's worth a shot for sure. So with that in mind, I have just pushed another branch DOUT-mode.

If someone having this issue can try the DOUT-mode branch first, because if that works, there is a good chance it'll work for all hardware.

[andyfitter]

I’ll give the DOUT branch a try in the morning. I’m in the UK so will be about 12 hours. Fingers crossed!

[quikote]

IT WORKS !!!! :-) I also had the "404 error" and no FinalStage SSID, but now I have flashed the new DOUT branch and it runs smoth as always. So you have solve the problem. Thanks again! The tested device was a new sonoff basic, arrived yesterday from amazon. Never paired with the app. Sorry, no information about the firmware version shipped.

[sillyfrog]

@quikote Great news! If you still have the output on screen, it's the "romVersion" is the version of the software. If this goes well for a couple of others I'll make this master. Cheers.

[quikote]

romversion : 1.5.5

[davorf]

@sillyfrog Since I've had the same problem, I'll try it tonight and report the results.

Best regards, Davor

[thefathefa]

I have tried the DOUT version and it did not improve for me.

Note that I don't have the 404 symptom : I am stuck at the exact same point as @donoo in the second post of this thread. I tried using my phone's AP since it seems it unblocked @donoo but no luck. I have a Sonoff POW version 2.0.4.

Not sure what to do next...

[czyz]

I tried the DOUT version –no luck. I still see the 404 error. I've attached the output of a flashing attempt.

test_sonota_dout_mode.txt

[davorf]

Hello!

I've tried DOUT branch (with and without legacy flag) and still getting error 404 and no FinalStage AP. I've tried it on Sonoff Basic and Sonoff Touch, but results are the same.

Best regards, Davor

[sillyfrog]

@czyz @davorf Looking at that output - it does look like the same 404 (I think - the timing makes it hard to be sure) - did you also try the DIO-mode branch?

@thefathefa Can any other devices connect to your PC (on port 8080) when it's at the second stage? My best guess is a firewall when connected to your home WiFi (but it's just a guess), it would also be worth trying with the --legacy flag in case it needs the alternate ports.

[thefathefa]

Well, I have to say I'm not too sure of what to test:-) At stage 2, should I understand that your script is setting up a web server that the Sonoff should connect to, while both Sonoff and my PC are on my home Wifi? Can I test this with e.g. my phone or another PC? As this is my first Sonoff that I'm trying to get to work before I buy more. I just ordered 2 basics to see if things get better with those...

Tomorrow I'll try from a mac.

I just tried with --legacy (and DOUT), no change.

[quikote]

Hi all. Sorry to hear that it didn't work for you, but the DOUT branch worked for me without any flag the first time I tried. Before that, I was trying around 30 times with the master branch and with and without flags. A not of combinations, but same result (404 and no FinalStage). Once I change to the DOUT branch the only problem I had was to change the FinalStage Wi-Fi connection to private instead public in order to download the firmware to sonoff. But it always happened to me all the times I flashed sonoffs in the past. Do I don't know why it worked with me. My setup was Windows 10 64 and python 3.5.2 and fresh sonido basic never user before, if it helps. Regards from Spain.

[czyz]

I forgot I'd ordered a 2nd s20_us, so I tried that one. Same 404 error with both the master and DOUT branches. Then I tried something new. I installed the EWeLink app, made an account, activated/connected/whatever the s20 within the app, and installed the 1.5.2 to 1.5.5 firmware update.

And after that, I tried SonOTA master -- no 404 error! It got all the way through the process to FinalStage, then it exited (I neither exited the script nor manually left the FinalStage SSID -- it must have disconnected for a moment). It never installed the image_arduino.bin.

FinalStage stuck around. I waited a long time, then power cycled the s20, it was still broadcasting FinalStage, and I could connect to it and was given 192.168.4.2. So I connected to my normal network, ran "./sonota.py --no-prov --serving-host 10.0.1.137", connected back to FinalStage, and the script appeared to run successfully and install image_arduino.bin.

After waiting a while, I noticed that FinalStage went away, but rather than connect to my network, the s20 was broadcasting a new SSID whose name started with 'sonota'. I connected to that, and a captive web portal window appeared showing the Tasmota firmware's interface - it was configured to connect to the wifi network 'indebuurt1'. I changed the details to those of my networks, and it saved, restarted, and I'm good to go!

I've since configured a Sonoff Basic and a TH10 using this same process (upgraded its firmware from 2.0.1 to 2.0.4). In all cases, FinalStage would stick around, I'd have to run the script again with --no-prov, and afterward I'd connect to the sonoff#### network to configure the device to connect to my home network. But in all cases the process was then successful.

I've got a few more devices to flash. I still have that initial s20_us that hits the 404 error. I expect that if I upgrade it to firmware 1.5.5 that I'll be able to successfully flash it with SonOTA. But if @sillyfrog wants one running 1.5.2 to test I'll hold off on upgrading it.

tl;dr: My devices initially wouldn't flash via the sonota.py script, but did so just fine after I upgraded their firmware to the latest using the EWeLink app.

[sillyfrog]

@thefathefa Correct, it's just a web server, so if you browse to http://:8080/ from your phone on the same WiFi, you should get the string "404: Not Found" in your browser. If you get "Connection Refused" or similar error from your browser, then there is probably a firewall in place, which you'll need to turn off.

For others: to confirm what @quikote said, it's important to completely disable all firewalls, or ensure each of the WiFi networks is set to "private" so incoming connections are allowed.

@czyz On a device with the older firmware, have you tried running it with the --legacy flag? I think this may work, it has worked on other devices with older firmware, so hopefully this is the same. Regarding the second FinalStage, do you still have the output, I have a feeling it'll be the same problem as #24 - I'm trying to figure out a solution to that one (which maybe just a case of making the exit point a lot smarter than it currently is).

[czyz]

I had tried --legacy before back when I was getting 404s. I didn't save the output, but it didn't get any further in the process.

• Here's the output of running sonota.py on the (upgraded to 1.5.5) s20_us: test_sonota_on_s20_w1.5.5firmware--FinalStage_doesnt_go_away.txt

• And here's the followup --no-prov invocation of sonota.py that got the s20_us to finish the process and stop broadcasting FinalStage. sonota.py --no-prov in order to finish an s20 that was stuck in FinalStage.txt

[sillyfrog]

@czyz Perfect, thanks, that matches #24 perfectly, so I'll have a think as to how I can address that.

Did you try the v1.5.2 with the DOUT-mode branch and --legacy? That combination should work - assuming my guess is right. If not, if you can send the output again that would be great. Cheers.

[thefathefa]

Update : I disabled the firewall, and I was able to get the 404 error when connecting from another device and the process moved on (but only after I hit CTRL-C because I thought it was stuck : i got then a full set out traces displayed which looked good!!! So good, some progress even if I'm not sure the CTRL-C is very good. It was then stuck a second time and hitting CTRL-C unblocked it and I got further traces looking good.

I then got FinalStage SSID displayed and faced the exact same situation as @czyz except that the script did not end by itself... So I killed it, retried following @czyz "process" and it seems I'm still stuck with

The "FinalStage" SSID will disappear when the device has been fully flashed and image_arduino.bin has been installed Once "FinalStage" has gone away, you can stop this program

I killed it a second time...

Now I have no led anymore on the device, it still broadcasts FinalStage SSID after I power cycled it... Let's see if I find a way to recover it...

[sillyfrog]

@thefathefa I'm working on stuff now for it to figure things out and not exit early, but you should be able to just run it again with --no-prov, and then connect to the FinalStage SSID, and after a minute or so it should be updated.

It will show something like this in the output: 2017-10-06 20:26:00,139 (INFO) 200 GET /ota/image_arduino.bin (192.168.4.1) 8682.74ms

If you are still getting the 404, try using the DOUT-mode branch, that should sort that portion out.

Finally, if you are still having issues, and have the output, please post it (as a gist or similar is ideal) and I can check it out.

[thefathefa]

@sillyfrog thanks a lot for what you are doing!

The current status for me is as follows Device has no led on anymore FinalStage SSDI is available and I can connect to it But nothing seems to be happening. I have tried with the --no-prov --legacy options but no luck.

And I'm with -DOUT version, yes.

See the traces of the last attempt just below and the full thing of what I did today here: https://github.com/mirko/SonOTA/compare/master...thefathefa:patch-1#diff-17cb741c72e4c1f190609d79a6b4883f
I tried to put it on github, I hope I did not do this wrong...

WiFi SSID: TheSSIDhere
WiFi Password: thepasswordhere

Using the following configuration:
        Server IP Address: 192.168.101.106
        WiFi SSID: TheSSIDhere
        WiFi Password: thepasswordhere
Starting stage2...
~~ Starting web server (HTTP port: 8080, HTTPS port 443)
~~ Waiting for device to connect

*** IMPORTANT! ***
** AFTER the first download is COMPLETE, with in a minute or so you should connect to the new SSID "FinalStage" to finish the process.
** ONLY disconnect when the new "FinalStage" SSID is visible as an available WiFi network.
This server should automatically be allocated the IP address: 192.168.4.2.
If you have successfully connected to "FinalStage" and this is not the IP Address you were allocated, please ensure no other device has connected, and reboot your Sonoff.
.........

The "FinalStage" SSID will disappear when the device has been fully flashed and image_arduino.bin has been installed
Once "FinalStage" has gone away, you can stop this program

[sillyfrog]

All: I have just pushed a few enhancements to the sonota.py in the DOUT-mode branch to better handle the "FinalStage" (and the reasons it was an issue previously). So please pull and update to that branch before doing further testing if getting the 404 issue (all going well I hope to make this master).

@thefathefa In my testing just now I found that while the Sonoff is in the FinalStage, it appears to stop after a few minutes - so I would suggest (after doing a pull, and running it with the new version options of just ./sonota.py --no-prov) - resetting the Sonoff, connect to the FinalStage SSID when it comes up, and see if that works. As always, ensure that all firewalls have been disabled, including when connected to the FinalStage SSID (on Windows there is a different firewall config for each SSID to my understanding).

[thefathefa]

ok, to be sure, by resetting, you mean power cycle it? I don't seem to be able to run the 7 seconds press any more, or when I do it has no effect on the led, which worries me a bit :-)