Don’t forget: It’s not the SWITCHING between the two modes that’s the problem. Switching is leaving some remnant in the Photon somewhere that prevents it from working.
Well, at least prevents it from working with Verizon and Xfinitiy/Comcast. I wonder if a totally different ISP would have the same problem. So for example, let’s say you do not have Comcast or Verizon as your ISP. I send you my source code (3k lines?). If you run it in MANUAL mode and you have no problem with cloud connect, we build evidence it’s Verizon and Comcast. I think our code runs ok without our PC board.
BTW, we always see the DNS as 0.0.0.0 when fetched from wifi. It’s not a function of dynamic or static.
Hey! Thanks for all the help! And thanks to everyone else around the world that helped.
–jim
Does WiFi.dnsServerIP() definitely work at 0.5.x? I’ve just tried it using 0.5.0 and 0.5.2 (can’t try 0.5.3 at the moment) on my Photon, and keep getting DNS=0.0.0.0. My cloud works fine. I’m using DHCP.
configured credentials:
ssid=XXXXXX security=wpa2 cipher=1
available access points:
SSID=XXXXXX security=wpa2 channel=1 rssi=-73
connecting to WiFi
connected to WiFi!
localIP=192.168.1.112
subnetMask=255.255.255.0
gatewayIP=192.168.1.1
dnsServerIP=0.0.0.0
dhcpServerIP=0.0.0.0
ping gateway=1
ping addr 8.8.8.8=1
device.spark.io=52.23.193.249
connecting to cloud
connected to the cloud
I’m pretty sure that dnsServerIP always returns 0.0.0.0 when retrieved by DHCP. So that doesn’t, in itself, indicate a cloud failure. But I threw the check in there, just to see what it would return.
If you want to rule Comcast/Verizon DNS changes out of the equation entirely… set your DNS Server IP to 8.8.8.8 (or 8.8.4.4), and use public Google DNS server instead of your ISP provided one. I suspect you are right in thinking that since you only check the DNS settings at boot up, if there are any changes after that, your code would stop working. If you think that is going to be an potential future problem, maybe worth adding a check for bad DNS settings, and falling back to 8.8.8.8 if it is wrong?
Regarding notifications of new posts, you might only be getting notifications when someone mentions your name or specifically replies to your last message. If you check down the bottom of the page, just above ‘Suggested Topics’, on my end it says Tracking “You will receive notifications because you posted a reply to this topic.” If you click on the “Tracking” button, you can choose from “Watching”, “Tracking”, “Normal” and “Muted”. If you wanted notifications for all new posts, you’d want “Watching”. If you’re no longer interested in this thread, you’d choose “Muted”.
@jim_hahn, good to hear you're on a way out of the ditch now
About the theory part 2:
Didn't you mention your two "seperate" ISPs are Verizon and Comcast?
If so, then ending the cooperation might well be a reason for both to change their previously shared infrastructure and for the sake of equality of "cost" of the split, neither of them was "allowed" to keep the old IPs.
Would this make sense?
Well, that was my exact guess re infrastructure. But it’s almost too crazy to be true. However, as a true scientific theory, it does support the evidence. We are searching old emails and internal work documents to see if we ever long ago saved our serial output stream. I cannot find it on my computer but my partner may as he wrote the code. This will tell us if Verizon & Comcast properly sent out the correct DNS in the past.
Might make sense, one way or another, for WiFi.setStaticIP(myAddress, netmask, gateway, dns); to return an error or warning status code telling the caller something is odd. For all I know, it already does return such a code but it’s not in the firmware documentation.
Makes sense for the caller to check their arguments and not rely on the function doing so.
Still puzzled as to what happened to the other dozen people on the forum that had the problem of safe mode not working. Their forum threads just stop with no resolution noted. Did they discover the same stuff we-all did and they just didn’t bother telling the rest of us? I think I will PM them.
–jim
Actually no, it doesn't, as there is no problem in setting the addresses, but instead in the addresses actually pointing to something that works. That in itself is a test you'd need to run if you thought it was a concern, and were making the code as robust as possible.
And you have to also remember the DNS settings are inherited from your router, hence the reason I suggested to reboot. But that doesn't fully answer the question of why the DNS was all 0s, and is has been raised as a possible bug.
Please let us know if you hear anything more from those other users, as it was quite odd that those threads don't come up with any resolution, and just ended. Hopefully they realised they had some issue in their internet connection and just didn't want to admit it!
I am trying wrap up my thinking (our thinking?) on this problem. Although I am personally satisfied with the outcome, because I can now do Build/flash, it’s not clear to me that the overall understanding of the issue at the nuts and bolts level has happened. In other words, I know how to workaround the problem, but workarounds are not solutions.
Stuff:
There is an apparent known bug in Particle land that WiFi.dnsServerIP always returns 0.0.0.0. See forum entry “Particle DNS resolution with long hostnames”. See entry from user named “fspezi” about half way down the forum entry. We have absolutely confirmed this. The DNS value written in DOES get used properly but it never gets read back.
Although it seems like several people have been burned by this, one of the posters was told that he should go edit the documentation himself. This seems like a major leap for a user to tackle.
Our project read back the erroneous 0.0.0.0 and then used that address in the WiFi.setStaticIP call. That read and setStaticIP occurred probably back in Spring 2016. It probably set the stage for the recent problems. Our mistake.
Even though this 0.0.0.0 usage mistake had been made on our part, up till, say, late August 2016 things worked OK. By that I mean that we could successfully use Build and perform flashes after initiating cloud connection. We needed that because we run normally in MANUAL. Said cloud connection could be invoked from a serial keyboard command issued to our application OR by using Safe Mode. This should not have worked but it did. Why?
Sometime in late August or September, we lost the ability to flash new code or enter Safe Mode. Nobody knows what happened. I suggest it would useful to learn what happened as it could help other users in future and might point to some other bug in Particle land. This loss of capability happened on all our Photons and happened at two different development sites simultaneously. Huh?
Another forum post, “Photon setup flashing cyan with a quick red burst” seems to detail several people with similar problems. Specifically that “a whole bunch of chips stopped working at the same time”. A user comment: “I am curious. Did all of your devices start mis-behaving at the same time? … That seemed to happen to me, as well.” What in the world could cause this?
These people were encouraged to work with “keys”. My take is that that sometimes worked and sometimes didn’t. For my problem, yes, I redid the keys early on and no joy. My reading of the keys issues as discussed in this post tells me it’s complicated and you have to be handheld to know what to try.
rickkas7 had me load tinker and I could issue commands to, for example, turn D7 LED on and off. For unknown (to me) reasons, that caused Safe Mode and Build/flash to resume working. Huh? (Yes, I had tried a new firmware version. No luck.)
We later found that shifting from ‘static’ to ‘dynamic’ also enabled Safe Mode and Build/flash to work. We can force that change with a keyboard command to our application. Now that we know more about the underlying behavior of DNS and the bug, it becomes somewhat clearer why that was. But we were lucky: Our app has this command to begin with to shift to dynamic. If you don’t have this, the Venus fly trap will nail you from using the WEB IDE ‘build’ or from using Safe mode.
I never tried it but perhaps loading an app via USB which only sets the DNS to a good value would have worked.
Special thanks to the elite forum members and particle engineers that put in so much time to help on this.
–jim
What was the system version on the boards at that time?
This might have been the hard coded DNS fallback in that system which got changed with one of the more recent updates.
I think the wording here (and in other threads stating the same or similar issue) is not exact enough. You might actually be able to enter Safe Mode but since it can't fully connect to the cloud you never get to breathing magenta. To prevent that misunderstanding it might be desirable to have the blinking cyan phase within Safe Mode substituted for blinking magenta to indicate you already are in SM but can't establish safe connection.
That's because the root cause was a different one but the fact that you were using static IP was not revealed at that time, limiting our responses to the more common causes (even unlikely ones since you didn't have the red/orange burst, but that seemed more likely than assuming your static IP).
Anyway, good to have your devices back in the flock
I suspect you are right in thinking that since you only check the DNS settings at boot up, if there are any changes after that, your code would stop working. If you think that is going to be an potential future problem, maybe worth adding a check for bad DNS settings, and falling back to 8.8.8.8 if it is wrong?
