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.
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.
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.
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.
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.
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.
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.
