Trouble connecting with separate DHCP server

My network is reasonably simple: there’s a wireless and wired DIR-865 router, and one of the computers connected to the network is a DHCP (and DNS, and…) for any device that connects to the network. All of my network devices–tablets, smartphones, an Electric Imp, and any regular computer equipped with a WLAN interface are able to connect to the network. However, my two Spark Cores won’t connect.

Specifically, the smartphone application is able to inform the Spark Cores of the WLAN authorization but once they start flashing green that’s as far as they go. In my DHCP server log it seems that the MAC address of the Spark Core is recognized and an IPv4 address is offered to the Spark Core. The Spark Core never seems to respond with a DHCP ACK, however.

I’m thinking that if all devices but the Spark Cores readily connect, then it’s probably the Spark Core’s firmware that can’t handle a separate DHCP server. (Indeed, the cores can connect to another router, which has a built-in DHCP server.) I suspect that the cores simply won’t talk with any IP address other than the router’s.

Is it a new core? A CC3000 firmware patching might solve the blinking green problem :slight_smile:

It’s about half a year since I purchased the cores. I’m not sure whether that’s new or old in terms of firmware versions.

Do you have a link to the firmware?

Half a year then yeah the patch is likely to solve the problem!

You need DFU-util to flash the firmware.

Thanks. I’ll try and see if that works.

1 Like

Post back if you don’t! But you sound techy :wink:

Regrettably, no luck. The flashing appeared to complete as expected (I tried with both the pre-built binary and by building it from source), but I'm seeing the same entries in the DHCP log as before (MAC anonymized):

May 7 16:18:25 home dhcpd: DHCPDISCOVER from 08:00:..:..:..:.. via eth1
May 7 16:18:25 home dhcpd: DHCPOFFER on 192.168.2.117 to 08:00:..:..:..:.. via eth1

This is by no means an advanced network setup, so I'd be a little surprised if the firmware is really that immature.

DHCP is handled almost entirely inside the TI CC3000 WiFi module, so I don’t think the problem will be in the Spark firmware. There are some call backs in the driver to say when it is done and to pass and get the information, but I don’t see a lot control that could be applied to the process. In fact the only call to the TI driver netapp_dhcp that I could find was to clear the current settings so it starts automatically asking again, but I could have missed something.

As a work-around, you might be able to call netapp_dhcp yourself with the correct settings but I am not sure where in the current flow you would have to do that.

Maybe @satishgn or @zachary could comment on this one.

1 Like

Hi @wolf,

Can you try the latest patcher from here? https://github.com/spark/cc3000-patch-programmer/blob/nobuttons/build/cc3000-patch-programmer.bin?raw=true

It might also be good to load the newer Tinker version as well, which also has a number of stability improvements:

https://github.com/spark/core-firmware/blob/spark_4/build/core-firmware.bin?raw=true

instructions here: https://github.com/spark/core-firmware#4-flash-it

Thanks,
David

2 Likes

I gotta ask this now:

Security type? Wpa wpa2 wep

Any funny SSID character names Or password?

1 Like

@Dave ,

Yes, that firmware binary seems to solve the problem. Thanks!

The flashing went slightly differently: instead of marking the flashing complete the LED went to solid blue for a few hundred milliseconds, then solid green, then flashing yellow. Then after the factory reset and the Smartphone-assisted authorization it was able to connect to my network.

Kenneth: it’s WPA2 security and no particularly special characters in the SSID or password. But I wouldn’t suspect this to be the culprit because the malfunction occurred only after a successful authorization.

3 Likes

Awesome! That’s the CC3000 patch I use during manufacturing, so it does some extras for me, like clearing wifi profiles, and resetting back into DFU mode. :smile:

Thanks,
David

3 Likes

That sounds like it may be worthwhile migrating a few features (like maybe a somewhat harsher factory reset) from the manufacturing version to the release version.

Or, it’s because the LED changed its color after the flash. Definitely. :wink:

2 Likes

OK, that’s freaking hysterical! As an engineer at a large tech company I’ve been there more times than I care to count.

1 Like

I couldn’t help reflashing one of my cores with the official firmware that I had built from source. It appears that once the manufacturing binary has been flashed, the regular firmware will work.

2 Likes

I guess I spoke too early. The spark core has been operating for about a week with absolutely no new code or other disruption, and now I’m seeing the same behavior as before: it requests an IP address and is offered one but never acknowledges.

I’ll try and see if reflashing with the “manufacturing” firmware solves the problem again.

Out of luck. The two Spark Cores won’t connect any longer; both are offered an IP address but they fail to acknowledge. The curious part is that one of the Spark Cores hasn’t even been turned on since it last worked, and how it doesn’t connect anymore. The DHCP server hasn’t changed either.

This is getting stranger by the minute. I had just connected my phone to another router hoping the Spark Core would connect to that one when the Core suddenly connected to the original router. I’m beginning to suspect this may have to do with the trouble connecting to channels above 11 in Europe that has been mentioned recently.

1 Like