Orange is an indication of no configuration at all, which would imply that the blinkup packet was not received. What device are you using to send it? The longer the setup packet, the more chance of a dropped frame (and unsuccessful blinkup) using the default android app.
I don’t believe there’s a minimum length. How long is your password?
I have just tried this a couple of times, an 8 character password will fail, a 17 character password will work. I can’t really see if the failure is during blinkup or during connection, i have the impression i see the first red flash during the blinkup near the end.
The blinkup is done with a HTC Hero with Android 2.3 (ie slow and old), i cannot see anything wrong with the blinkup itself.
I’m using WPA2-PSK and a homebrew impee. Once connected everything works so i am assuming the imp, impee and connection are fine.
I have just done another experiment, i have erased the imp config (the imp blinks orange). Blinkup with an 8 character password will fail : red blink(s?) and then orange blinks and after reboot the imp will blink orange.
I can blinkup a 17 char password.
Enough of the blinkage, i have a working setup an going to try to build a twittering catflap or something 
The red blinks immediately after your blinkup mean it didn’t “take”. The issue may just be dropped frames. I’ll send you the slow blinkup to try that out…
FYI I see exactly the same problem. I have an Apple Airport Express, send the details fine followed by endless orange/red. I’m in Australia so it’s possible that the wifi was on net 13 instead of 1-11, but I didn’t try manually setting that. Using the tethered network on my phone worked fine.
If it is a problem connecting to wifi though, why does it blink orange/red instead of just red?
There are some wifi states which don’t indicate very well (eg corner cases on wifi association, which are being fixed).
If you were on channel 13 then yes a US imp wouldn’t find you as it only looks at 1-11. You can manually set the channel in the airport config software.
Wondering where this issue is at. I’m also in Australia & my new Imp will not connect to the cloud (orange/red flashing) service using my NetComm NB16WV & WPA2-PSK & channel set to 5. The Imp is on the WLAN as I can see the DHCP lease and ping its IP from my laptop. I can also see Router NAT table entries from the Imp to 184.169.136.13:31314 I can browse to http://imp.electricimp.com from my Laptop which is on the same WLAN. I’ve also removed encryption but got the same results. As soon as I blink it to my iPhone hotspot it works fine??
Im am having this same problem. Off->orange->red fast. The imp does get an IP address, I can see it in my DHCP server leases, and I can ping the imp as well. But it sits in this connect-to-cloud loop. It also does NOT show up in my planner account.
The router is an engenius, the WIFI is probably not the problem since I can ping it. DNS/DHCP is served by a win 2k8 R2 server.
Please help, I’m dying to try out my imp
Edit: I can access this web site fine from any PC on the network, wired or wireless.
@ncostes: This could be a router-rewriting-MSS issue. Got another wifi network you can try it on to rule this out?
I do not, but I can change settings in the router, access point, DNS server, or DHCP server if you have any idea what could be causing the problem.
Thanks!
Edit: I mean I can make the effort to connect to a different network by going somewhere else, would just be easier if I could adjust something in my router if you think it’s causing a problem. Unfortunately most ppl I know, I’ve set up their routers and they’re using the same engenius line I am using.
Edit1: No settings in my router for setting the max TCP segment size. I’ll try another router if we think that’s the problem.
The routers that rewrite the MSS are doing this because of a bug, it’s not a setting… the only workaround right now is to use a different router. We have a server-side workaround that should help but it’s not yet deployed.
Ok I used my iphone as a hotspot and was able to connect to the servers and load sample code. I reblinked it back to my home wifi settings and got back to the off-red-orange cycle, then it turned off.
What can we do next?
If the issue you’re seeing is MSS related, I’m afraid there’s nothing you can do short of using a router that doesn’t do highly dubious things with packets passing through its NAT.
As I said, we have a proposed workaround on the server side (tell the stack to ignore the MSS sent by the client) but no timescale for that just yet.
So there’s no way to know ahead of time if any particalar site’s router will allow access to the electricimp cloud service? That sounds like it might be a barrier to general adoption.
Hopefully the at some point that server-side fix will be implemented.
It’s a shame we can’t have local servers. I imagine the cloud aspect of it could also be a barrier for OEMs who don’t want to store their IP on someone else’s servers. I guess that market space is already occupied by other devices (e.g. NetBurner etc.) though I haven’t seen anything this small before.
My interest was hobbyist and education only so no big deal there, I can wait until there’s a server-side fix or my router dies or I get so curious enough to watch the LAN and WAN ports with wireshark to see what’s really going on during NAT.
Thanks
If you do watch with wireshark, the failure case is when the imp starts up a TCP connection with a receive MSS of 576 (by setting the “MSS” option in its SYN packet, RFC879 section 3), and the router bogusly rewrites that on the way through to the origin server, so that when data starts coming back it’s in packets with >576-byte payloads.
We got a bit taken by surprise by that, as it hadn’t really occurred to us that a router might muck that up. So far we’ve only found one specific model of router – not an Engenius – having the problem, but your symptoms do sound identical, so it would actually be very interesting to have a wireshark dump.
Peter
@ncostes: the aim is 100% compatibility with all routers; we’ve already worked-around bugs in various routers but obviously there are an almost infinite number of varieties so there’s a certain amount of field exposure needed to achieve that aim.
Though vendor code is on our servers, the IP remains theirs, and data passing through our servers is not stored or mined (unless a vendor explicitly stores it in their agent local storage, obviously). This hasn’t proven to be an issue so far, though I’m sure some categories of customer will find it unacceptable.
@peter I can put a hub on the WAN side and watch with wireshark, without putting a hub and separate access point on the LAN side, what’s a modern airsnort equivalent you would use to watch the IMP’s traffic? (I can make the WIFI network open for the experiment). It’s been a few years since I used airsnort and a quick peek at their page shows it is not still maintained. Would prefer a tool that’s quick to set up as it’s a one-time use thing here, great if it works on windows, but I can make do with OS X or Linux as well.
@hugo Well maybe someday local servers will have a business case, who knows. Aside from the security nightmare of all these network controlled devices with traffic over the Internet, the IMP is super cool. We give up security for convenience, it’s a constant tradeoff (love my icloud, can’t stand that my email sits on an IMAP server and gets transmitted in cleartext anyway). At least with local “cloud” servers IMP users would only be vulnerable to a local attack. Anyway, the IMP is a super cool idea and amazing implementation. Everyone I show it to thinks it’s really cool. Unfortunately I can’t show it off working yet (work has authenticating proxy and home has an uncooperative router) and those are the only places with people who would be interested.
Will post if I have any results.
If you have a mac, then wireshark works in monitor mode (you can see all unencrypted wifi traffic). No need to use anything like airsnort. We’d definitely appreciate it if you could monitor the traffic - if you look at the wifi side, you won’t see the NAT rewrite but you’d see the results - ie the packets from the imp server to the imp would be above 576 bytes.
The imp’s traffic is all TLS encrypted… I’m amazed your provider is not offering TLS secured IMAP!
It’s possible we’ve addressed this issue now on the server-side, but that needs validation. If anyone has had issues in the past (imp blinks-up ok but doesn’t connect to the server on a particular router) then we’re really appreciate it if you could try this again and let us know if it works now.