Spark won't connect using TCP/HttpClient libraries (SOLVED)

Try this code and see what you get..

Hi, thanks for the quick reply!

Here's the output:

0.0.0.0
-85
900
0.0.0.0
-85
900
0.0.0.0
-85
901

I have also replaced "www.google.com" in my previous example and used instead the fully-resolved IP address "173.194.45.51", but it also fails to connect.

How are you entering the ip address? it wont work if you enter it as a char string like that.

change it to an IPAddress type using this:

IPAddress server(173,194,45,51);

@alinanco @Hootie81 Some cores can catch a problem where they no longer can do DNS lookups. The TCPClient connect method can either accept a char * or a IPAddress. Any char * passed will result in a call to gethostbyname that fails once the core gets into this bad state. You should try creating the IPAddress as @Hootie81 recommends and pass that IPAddress to the TCPClient.connect call.

If you absolutely need DNS lookup capabilities then there is a library you can add to your application that you can use for DNS lookups and then pass the IPAddress to the TCP calls.

I have noticed not all Spark Cores have this problem. I have 5 cores and one has this problem.

I tried setting the IP as suggested by @Hootie81 and works now, I didn’t realize about the proper way to do so, thanks @Hootie81 and @mtnscott for the suggestions!

Ive just been doing some testing and ill need some spark help to add some bits to the spark code… Maybe @Dave or @zachary could help us out… I’m not fluent enough with git to do pull requests yet…

This will help with debug of this reoccurring DNS issue

trying to keep it in line with the WiFi class… most of the guts of it was there already. I have added a few lines to get the current DNS IP from the core. I build local and it works on my core at the moment, and shows a good dnsIP, but im sure on some of these other DNS mysteries it may show 76.83.0.0 as that seems to be the ip alot of people get and i had it on one of my cores that has since passed away.

in spark_wiring_wifi.h line 48 i added:

IPAddress dnsIP();

and then in spark_wiring_wifi.cpp line 49 i added:

IPAddress WiFiClass::dnsIP()
{
        return IPAddress(ip_config.aucDNSServer[3], ip_config.aucDNSServer[2], ip_config.aucDNSServer[1], ip_config.aucDNSServer[0]);
}

for debugging i add to the user code

Serial.print("DNS: "); Serial.println(WiFi.dnsIP());

Hi @alinanco

It would also be good to know if you are on a “slow” network. The TI CC3000 has a timeout around 1 second for DNS lookups which normally is fine (when I measure other hosts on my network, for instance, I get answers in around 100 to 150 ms (less than 0.15 second)).

Hello,

No, my network is not slow, I also tested this with 2-3 more networks with the same result, I will try with the suggested DNS library and see how it goes.

1 Like

@bko & @Hootie81 I’m willing to test this. I have a 1.5mb DSL internet connection. I have 8 cores, some I have not yet tested for this behavior. I use three constantly, one demonstrates the DNS problem, the other two don’t. The one that has the DNS problem did not alway have it. It worked when I first started using it but now it consistently fails to resolve DNS without the additional library. I have not built locally in months, between this and the I2C problem i might be motivated to getting the environment back up and running. In the mean time if you want to make .bin files available I can test on my failed core and working core.

In a few weeks we are hoping to release our software. For that product release we can’t depend on a local build as we will be releasing the application as Open Source and it will need to build in the IDE. So hopefully we find find a fix that could be pulled into the IDE. :smile:

I have just added firmware.bin to the DNSClient in the example folder, https://github.com/Hootie81/DNSClient

Start a terminal window at 115200 baud, as you would normally start one, It will print the Local IP and the DNS IP

If the DNS IP matches your router then you should be ok, but i suspect it will be 76.83.0.0

1 Like

Just so everybody knows, you don’t need to change the WiFi class and compile locally to access the DNS host.

Try this in the web IDE:

void setup() {
    Serial.begin(9600);
}

void loop() {
    IPAddress dnshost(ip_config.aucDNSServer[3], ip_config.aucDNSServer[2], ip_config.aucDNSServer[1], ip_config.aucDNSServer[0]);
    Serial.print(dnshost);    
    delay(10000);
}
1 Like

That’s handy to know… i dodn’t even think to do it there… i just looked at how the local IP was done and found the DNS stuff was kind of there already…

1 Like

@bko @Hootie81 Yep, that is the IP my messed up core has. The rest of my cores have the router as the DNS ip. I tried to reset the IP on the bad router but it does not survive a reset

@bko - Any idea how to get the core to pick up the correct DNS IP?

Here is a thread on TI’s support forum discussing the problem

http://e2e.ti.com/support/wireless_connectivity/f/851/t/370724.aspx

They reference the problem is related to static IP address, but we are using DHCP and the problem exists. How can we check which TI firmware is running on the Core? The thread mentions that 1.11 works but 1.13 fails. Is there anyway I can check my batch of cores to see what firmware they are running?

Its a bit above my head… maybe @bko can chime in here, im not sure if anything else needs to be done…

I think if you do a WiFi.clearCredentials(); it will set the DNS host in the cc3k back to 0 then next time the core boots it will be in listening mode, and you can enter your wifi details again.

so clearCredentials clears the nvmem and calls Clear_NetApp_Dhcp(); which sets the cc3k to DHCP and clears the DNS

If it works to clear the issue maybe we can do a check at some point in the firmware, and if it finds the strange IP it can fix it itself?

@hootie81 The call to WiFi.clearCredentials appears to clear NVRAM (or at least what is being displayed as the DNS IP address in ip_config.aucDNSServer) however after setting the WiFi credentials and rebooting the DNS IP returns to 76.83.0.0

its the bit after the clearing nvmem, i think that should do it, clear_netapp_dhcp calls netapp_dhcp that sets the IP, subnet mask, gateway and the dns to 0. but like i said its over my head… i dont understand c++ let alone c

I did and it did not make any difference. I know it reset the WiFi credentials because the core went to blinking blue and I needed to set the WiFi credentials. But after doing that DNS IP still stuck on 76.83.0.0

So maybe I need to return the core to Spark and have it replaced.

You can figure out what version of the CC3000 software you are running since the cloud connection reports that back so deep update can be applied if needed. Try this:

curl https://api.spark.io/v1/devices/<<device id>>/?access_token=<<token>>

I believe the deep update version is 1.28.

@bko, thanks i just checked it and its at 1.28. I think this core is just not going to recover. I can’t really use it as it almost always gets the 76.83.0.0 DNS ip address. I’ve written an app that will turn off the WiFi, reset the settings, turn on the WiFi and test the DNS IP. It takes several attempts but eventually I can get the correct DNS IP setting. But it will never keep it after a power cycle.

Well after days of troubleshooting a bad core and not being accepting of just adding my own DNS lookup I put together a utility program that will help you understand what’s going on in your core (or at least show what’s broken).