Stuck with an issue here, it seems that My Electric imp is stuck in a “firmware update triggered” mode, and its been hours since it has shown this in the log.
I have a linksys wrt54g router and the imp has been working flawlessly before but only now has it been stuck in firmware upgrade mode. Any help would be appreciated.
I have tried to remove any previous blinkUp setup and sent a new configuration using the iPhone app but to no avail.
Its a dev edition Imp. And i have also checked the channel being used in the router (its using channel 6) so i have that ticked.
Update: sorry moving this post to the hardware section.
Another thing i have just noticed is that the imp server url is showing up as “not running” in the IDE. after hitting the url i just get “this webpage is not available” in chrome
and the Imp side shows offline. I guess this is probably normal behaviour during a firmware upgrade, or I may be wrong.
I have not been able to figure out a way to see if the routers traffic can be sniffed, i have the logs enabled on the router, but it seems the feature doesn’t work. Logs are empty always.
Anyways, I did try to ping the upgrades.electricimp.com site from my pc which is connected to the same wifi router and I get the authentication dialog in chrome, which would mean the router does allow accessing the website.
Also just a heads up, the imp is located in Chennai, India.
I would love to get my imp back up again. anything else I can try ???
latest logs as of today are given below:
014-08-31 03:02:47 UTC-7 [Device] ERROR: the index ‘crash_to_force_reboot’ does not exist
2014-08-31 03:02:47 UTC-7 [Device] ERROR: at unknown:5
2014-08-31 03:02:54 UTC-7 [Status] firmware update triggered
2014-08-31 03:07:21 UTC-7 [Status] firmware update triggered
I’ve also seen something similar. I have two imps on my desk. One of them updated over the weekend and the other I has tried to update this morning and after 15 “firmware update triggered” in a row (less than a minute apart), I switched if off and on. It has connected to my wifi network, but was silent for 10 mintes, before beginning the cycle of “firmware update triggered” again.
I have field units that have not yet update and I will hold off doing anything with them until I can understand what’s going on.
@coverdriven yours are because your devices was specially named to receive an early beta and because of the debug you’re helping us with. This doesn’t affect “normal” devices - all non-blessed devices (aside from the people helping us with tests on connection reliability) are on 30.10.
knaresh89’s ones appear to be because his device isn’t able to get to port 80 to download an update.
This is happening for me too. You’ll remember that the last time my Imp tried to download an update (when I first bought them several months ago) I had exactly the same problem. Can you see my imps requests?
I tried the trick I used last time, using a tcp relay, but thats not working this time - the tcp tool just gets flooded with connection requests, indicating the way the imp does an update has now changed and can no longer be tricked successfully into delivering requests to a relay server.
I have also seen this in my server log:
2014-09-18 19:40:32 UTC+12 [Device] ERROR: the index ‘crash_to_force_reboot’ does not exist
2014-09-18 19:40:32 UTC+12 [Device] ERROR: at unknown:5
2014-09-18 19:40:37 UTC+12 [Status] firmware update triggered
Note: The imp is just stuck with the blinkup code for “downloading update”… but never completes.
I have tested my device with two of the 3 imp cards I bought at the same time… exact same result.
Another Note: I can definitely get to the upgrade server on port 80 on my network, and I have tried different internet connections (both my Cisco router, and an iPhone over 3G network). When I hit the address with a browser I get an HTTP Basic auth request…
Sorry, mac address is the useful thing here as that’s what gets upgraded. I can find the last mac used in that device ID if you aren’t swapping them about?
Looking in the logs, it seems like there’s some sort of web proxy between the imp and the upgrade servers; nginx is returning an HTTP 304 response to your request, ie a conditional GET has been issued.
The imp doesn’t issue conditional GETs. Does your ISP operate a “transparent” proxy?
I don’t know how I would know that - but my provider is Vodafone New Zealand - had you have anything similar from others on my ip range?
Unfortunately, my mobile operator is also Vodafone…
…found some forum messages which suggest Vodafone is operating a transparent proxy… these also suggest I may have no luck getting them to look at the issue. What else can be done?
Hi again Hugo,
I’ve taken my devices in to my employers office, and connected to that wifi (ISP is Orcon.net.nz) - and indeed the firmware upgrade went off without a hitch.
This does, however, mean that every time there is a firmware update, my circuits will just stop working until I put them in the car and drive them in to the office… also anyone else in NZ with Imps on the Vodafone NZ network (ok, a small market indeed compared to your USA base) will have the same problem.
Would it be possible to just configure the Imp webserver to ignore proxy cache rules and return an HTTP 400 result every time? Your imp device firmware would never issue a request for the firmware payload if it didn’t really want it now would it?
I only suggest this because it’s nearly impossible to get Vodafone sys-ops to change anything on their end unless the whole country is screaming about it.
Aside: I wonder if the fact that the imp downloads the firmware twice in quick succession contributes to Vodafone’s proxy being so aggressive and injecting the cache condition header?
The imp’s upgrade system should work fine via a transparent proxy, unless the proxy is mucking with the file in some way (which it shouldn’t, as it’s of type “application/octet-stream”).
