SparkTime broken? [SOLVED]

I was gleefully using SparkTime in my project when it suddenly stopped working. The UDP connection was failing. I noticed that the SparkTime.begin() function takes a string as a server name. However, the docs imply that UDP.beginPacket() takes a 4-byte IP address for the remote connection. Did something change? The SparkTime source is passing in the string:

_UDPClient->beginPacket(_serverName, 123); //NTP requests are to port 123

So I changed this to:

_UDPClient->beginPacket(IPAddress(204,235,61,9), 123); //NTP requests are to port 123

…and pow - it starts to work.

Hi @dwfick

This is actually a good indication that DNS is broken on your core.

The TI CC3000 WiFi part gets into a state where the DNS host is an illegal value of 76.83.0.0. It is not known why this happens but re-patching the TI part will fix it. You can run “deep-update” again and get the TI part out of this condition.

To test this, you can run this code with the core hooked up to a serial port to see what the DNS host is:

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);
}

// a value of 76.83.0.0 means DNS setup did not work

Ah! Thanks @bko !
Since my TCPClient was suffering a similar issue I was highly suspect of the DNS configuration.
I just didn’t know about the ip_config member - sure enough it is 76.83.0.0.
Will do the CC3000 deep update.
One more for my tips-and-tricks list.

1 Like

Hi @bko,
this problem occurs here as well, is this deep update a permanent solution?

Unfortunately it is only “permanent” until the next time the TI part goes wacky.

If we had repeatable way to make the TI part fail, we might be able to debug it but I cannot find a way to make the error happen on command. Many of the folks affected by this problem have what I would call “funny” networks with high latency or new types connections, but that could be coincidence.

@mtnscott wrote a tool described here to look for this and other problems:

And a more “permanent” solution is to use a DNS client outside the TI part that @Hootie81 wrote/ported.

3 Likes