We have a bunch of photons here. With initial configuration they connect successfully, only to drop the connection moments later. After than they can’t get online anymore, keep blinking green. We have a Juniper wifi controller with 4 identically named access points, all both 2.4Ghz and 5Ghz, b/g/n. All other devices here (tons of laptops, iot controllers, etc) work fine. We’re out of ideas, anyone know what’s next?
did you update the Photon system firmware to 0.4.5 and see how things go?
Having the same name for both the 2.4 and 5GHz might be problematic, since the Photon can only handle the 2.4GHz one. Is there a possibility or renaming them (even for testing purposes to check whether or not that’s the issue)?
I did just now, dfu-util’ed 0.4.5 onto it. Didn’t seem to help but thanks nonetheless.
Thanks — I think so, I’ll try. I would hope that’s not the issue, since we can’t do this permanently. More importantly, I would expect many customers to have similar situations so it wouldn’t be a good thing for P0/P1-powered products, or am I missing something?
Interestingly, the CLI shows our four AP’s as one (as do laptops), yet the iOS configuration app shows four identically named APs in a row. Does the photon try to connect to a specific one of those four, or any of the four? If the former, that might be (part of) the problem.
I think it connects to the one with the strongest signal if all are of identical SSID and security type
Nearly! It connects to them in the order they were added.
Is your wifi controller trying to ‘force’ the photons to another access point, or is it rejecting devices that connect at certain connection speeds? Is there a way get more insight into what the Juniper controller might be doing?
Have you confirmed that they actually get connected to the cloud (breathing cyan) even for a second or two? If they can’t connect to the cloud, it could be a firewall issue with TCP port 5683 (CoAP). That’s my initial two cents.
The multiple identical network thing is just showing you what your wifi really is. Since you have multiple access points/repeaters/extenders, you have multiple distinct devices broadcasting the same SSID. Computers will hide that and make it look like a single network.
Yup, they connect for 2-10 seconds and the imp dashboard shows them as online.
@mdma “in the order they were added” — wait, so it knows about the BSSID in addition to the SSID?
@Dave I don’t think it forces clients to APs and it’s pretty forgiving/broad on speeds and channels. I’ll do some more digging!
Just to elaborate on the dual-band problem: Many dual-band 2.4 and 5 GHz routers try really hard to move traffic to the faster 5 GHz band (Apple routers seem to be a particular problem) so the symptom is usually that your devices can connect for some time and them suddenly they are disconnected and need to be reset to connect again.
This sounds just like your problem except that your problem happens a lot faster (2-10 seconds you said) than most other cases I have seen. Changing the SSID of the 5 GHz band temporarily makes it impossible for the router to try to move devices to the high band and proves what the problem is. You would then want to look for a router setting that prevents moving connections to the higher band as a more permanent solution. Juniper calls this switching to the high band “band steering” so you can check the settings for your particular model.
In my opinion, until you eliminate the 5 GHz band problem as “the problem”, there is no point in trying anything else.
For an AP mode device, the BSSID is just the MAC address of the base station. It is broadcast in every beacon packet and used in almost every packet. I know that wiced does give the BSSID when you do a scan for all WiFi networks, but I don’t think that is returned to user level today. I am not sure how that could help you in this case.
Not following you here. Simply the order the WiFi networks were added to the device. So If you add Network A then network B it will try them in that order. (Oh, one small detail, it’s in fact the reverse order they were added, so the network added most recently is tried first.)
Quick update—we fiddled with the Juniper settings, the good news is that now the photon is online. The bad news is that I haven’t been able to reproduce what setting might have done it
@bko; I realize this is an old thread but it seems I have been battling this issue for awhile. My situation is exactly as described; several photons connecting to an Apple router which has both 2.4 and 5GHz enabled. Photons work well but poop out after hours or days, sometimes weeks but eventually WiFi stops working. When it stops, the Photon blinks green and never reconnects.
How should I best battle this problem? Certainly, in my lab I can do whatever I want with routers and change names, disable bands etc. But our (eventual) customer may have this exact situation so I need a permanent solution without asking our customers to get technical.
I am thinking to implement a watchdog timer that eventually resets the photon if it is not restarted in time. That might be good for other scenarios but the general thought to rely on a complete system reset when the WiFi craps out is just not right. Alternatively, I did not see a system call of sorts that is activated when WiFi disconnects, additionally there are no ways to just reset the WiFi unit.
Sooh any ideas?
I have not seen this problem in quite some time, but if it is the same old problem then the problem is in the router–it is trying to push traffic to the 5GHz band.
I think the solution is only possible in the router and the simplest way is to make the SSID for the 2.4 and 5 GHz bands be different, such as, “my24network” and “my5network”. Then there is no chance of confusion. There might be other ways such as MAC address filtering etc. but I have not tried them.
I would try the name change and see if that fixes it for you. If not then you could have a new problem with similar symptoms.
Just dropping by to say we can finally confirm what @bko and @Dave said — we’ve determined our routers tried to push traffic to 5Ghz, in part because of uneven power distribution between 2.4 and 5ghz bands. Bad router placement will exacerbate this problem. Splitting SSIDs is a sure-fire fix, though there are more subtle ways, such as better router configuration and placement. All in all we’ve come to believe this a problem with routers, not with Photons. (actually, lots of iot and mobile devices were impact by this). As such we’re completely revamping our wifi network.
@bko I did name the 2.4G vs 5G SSIDs differently and this is happening. So per your msg, this appears a new issue But back to my original post; is there no way to intercept the network going bonkers? At the very least I can then do a system.reset() or anything else that makes sense.
You can take control in manual mode and fully manage the cloud connection. @rickkas7 has some nice examples but I couldn’t the exact one I was looking for just and have to run off for a bit.
I think you should see if you get blinking green with the stock Tinker firmware–I will bet that you won’t. Then it will be a matter of figuring out what is blocking things up.
@bko; yeah, I have the tinker app running to prove that exact point. Also changing the configuration to manual mode and hope to log when comms drop off, perhaps I can correlate it with some other event… Thanks for your advice.