ICMP implementation: The fact that Spark doesn’t answer to “PING” is inconvenient, especially when trying to verify that Spark is still alive (typical when CFOD, crash occur without notices or with DHCP address change)
Permanent IP configuration: This is actually an application reliability problem, typically when DHCP server is managed by an ISP. This means that the IP address may change after reboot or at DHCP leasing time expiration, making the application unreachable locally, across firewall or with DNS and port forwarding.
As far as I could retrieve topics about theses subjects it is unclear for me if these are part of future improvements.
Point 1 about ping not working (after deep update that is) is handled inside the TI CC3000 WiFi module. I am not sure it is in Spark’s control to fix this one.
Point 2 is a general problem for devices on the internet and is why services like dynamic DNS were invented. You can work around this by having the core periodically broadcast its IP address using a Spark.publish() event (or UDP packet etc.)
Does the broadcast IP solution not work in your use-case?
Hi @bko
Strange that such a simple IP standard is not implemented by TI, but I can live with that
Permanent IP is really an issue, and dynamic DNS is not the solution. If you are behind an ISP using local IP address.
First because local applications are not reliable (if the local IP change always) and there is no way to discover that (beside implementing a local DNS server!)
Secondly if dynamic DNS allows to resolve the official IP address associated to the ISP router, the only way to access local IP address from the Internet is by configuring IP port forwarding (PAT + NAT) from the official IP address (discovered by Dyn DNS) to a fixed local IP address using port mapping.
Robert
On ICMP echo: it used to work before the “deep update” patch supplied by TI. Now it doesn’t and the speculation is that they had to chop that to make code space to fix other problems.
On Permanent IP: do you have solution you like for a desktop computer? You seem to be saying that there are no solutions to this problem but I don’t believe that since people make it work in a variety of ways for desktop computers. The Spark cloud completely solves this problem and you never need to know the IP address of your devices in order to use them.
Are you asking for a static IP address that you set? That is possible and there is code here in the forum showing how to do that. Spark may implement that as a WiFi function in the future but you can set it today.
Hi @bko,
Most of the common users desktop applications are making access TO the Internet from a local net, same with the Spark Core, using the provider public IP address as source to a well known address and port. Reply is not a problem because the ISP router knows how to map the return private address and port .
I need to build nodal application that resides on a local network, eventually accessible FROM the Internet (typical domotic applications).
Permanent IP address is basic and simple, I don’t want to build a dedicate DMZ with DHCP/DNS or complex procedure that will monitor my network informing the application that master/slaves addresses are changed.
Note: I have tried the sketch of https://community.spark.io/t/static-ip-not-static-dynamic-resolved/4707.
First it doesn’t work, Spare Core still uses the DHCP address, secondly it crashes the Core (seems to reboot at regular interval).
For what I have seen until now (after 2 weeks of Spare Core experimentation) and beside the numerous good features of it, I see really this point an an issue that limits the usage of the product (at least for what I have to do).
Robert
what about people who are not using the cloud or want to use the spark as a server and don't want to/can't muck around with router's arp tables to configure static dynamic ip's based on mac? or how about people with a security requirement to configure ACL's - dyndns is nobody's solution to anything lol.
i've already proven that its possible to do static ip here so we just need a clean up of that and some changes to spark setup to allow it to be configured.
the lack of static ip is bizarre, it totally removes the possibility of using sparks in a corporate environment.
Lots of people want to control things from the global internet to their local subnet. People doing home automation, people doing NAS, RPi, watching their home cable TV on a remote device over IP, etc. etc. etc. There are some patterns that are successful here that do not involve static IP addresses. Dynamic DNS is one such pattern but there are others.
Maybe you and @sej7278 can figure out why his code didn't work for you to set an IP address.
People who can’t or don’t want to use the cloud don’t have to! It is an open-source project and you are free to roll your own solutions at any time.
Maybe it is a regional thing (I’m in the US) but I have never seen a corporate wireless network with static addresses anywhere I have worked or visited. Wired networks–sure, all the time, but never wireless. I am sure it different in your corner of the globe.
as far as corporates go, sure they may have dhcp, but if you’re running a server you need static, and a corporation is not going to let you edit the router config to allocate a static dynamic, or use dyndns.
every corporate (hell cybercafe even!) wifi network i’ve used has outbound filters so i doubt the cloud would work either. you couldn’t even ask to be put in a dmz or ACL whitelist if you don’t have a static ip.
dyndns on your home lan isn’t going to work as you’ll need a static internal ip to portforward.
as far as my static setup not working, that’s the old way before the new wifi routines broke everything the new code i linked to here works now, even for the cloud (which didn’t work before). in fact you can expand it to bake wifi credentials into your script too if you want using WiFi.setCredentials()
I still believe that permanent IP address option is a “must”. I was testing the configuration pointed by you and it works perfectly, so beside the “Ping” issue everything is OK for me.
You may continue to argue about the reason to use dynamic IP addresses and Cloud access, however, I am pretty sure that other people will be happy to know how permanent IP set-up is to be done, which should be clearly documented (I was unfortunately not be able to find theses new settings through the search engine, before entering this note ) .
@rrobinet1 - my code isn’t documented as its unofficial, i figured it out from the msp430 code and TI docs. its only a proof-of-concept and not very tidy or configurable, but hey i’m not a spark employee and external pull requests seem to take forever, the cc3000 code is beyond me anyway.
it should show up in a forum search though - probably didn’t as you call it “permanent” instead of “static” ip.
i agree its not worth arguing over if its needed or not. lets just say have you ever heard of a single network product that can’t do static ip (or ping for that matter) ?
the new code i linked to