Using Spinneret to keep a VPN connection open

NWCCTV

I have a client that just moved to a new location. They are using 2 Ethernet connected Time Clocks at their old location and one at the new location. They plan on at a minimum keeping one clock going at the old location. They have a VPN connection from the new building to the old building. The Time Clock software is on a computer at the new location. The clock at the new location works fine. However, the 2 clocks at the old location seem to lose their connection about every 24 hours or so. I have a couple Spinneret's lying around and thought that maybe I could set up a web server at one or both locations and have them communicate back and forth every hour or so just to keep the connection active and see if that resolves the problem. I have never used a Spinneret in a "Real World" application and would like to know if this would work. ( I really want to prove a point to their current IT guy that "Thinks" he knows it all and swears this would not work.) So, my question is, has anyone ever used a Spinneret in this way or do you have a better suggestion? I would like to keep it to parts on hand if possible. I have a couple Spinneret's and a PINK, Wiznet boards with POE adapter and several QS boards.

xanadu

So the "IT guy" is leaving the problem for you to solve and denying a solution he probably doesn't understand... I thought I was bad. The VPN probably supports a keep alive too.

There are a lot of Spinneret demos link in this thread - http://forums.parallax.com/showthread.php/151794-NIST-NTP-Code-for-Spinneret

Since you have a site to site VPN you would need to communicate over the tunnel to keep it alive. So you'd be limited to communication over the VPN and not the web. You could do this with one device on just one side. I haven't tried the Spinneret ping demo, but if you put the Spinneret on one LAN and ping the other LANs router it should keep the tunnel open.

NWCCTV

Yea, He apparently does not like to come out from behind his desk. He said one of the clocks was bad and come to find out it was a port on the switch he sold the client!!!!

Thanks for the link and advice. I will play around with it a bit and talk directly to the client to see what they want to do. Worst case is that it does not work. Best case is it works and I am the hero!!!

mindrobots

Not to take a job away from a Propeller but if the clocks are in PCs and the PCs are on each end of the VPN, can't they just play PING pong every so often to keep it alive?

NWCCTV

The clocks are not on a PC. They are standalone clocks with Ethernet Modules.

mindrobots

Sorry, miread the original post.

Do the clocks respond to pings?

xanadu

The time clocks usually talk to time card software on a PC, but only when the PC requests the connection. From there is it usually uploaded to payroll unless they do that in house. The newer biometric clocks can store a ton of data and are usually only polled before payroll time.

I have the same situation, a business split into multiple offices with a site to site VPN. Usually the tunnel will be opened by a user connecting to a server, before time punches are collected. If the clocks are the only thing on the tunnel then that would be different. The first connection to "wake up" the VPN usually times out. If that timeout results in an error the user cannot process it results in a trouble ticket, or two. That kind of stuff around payroll time can cause a big panic.

I can get a ping response and http response from the clocks on my network. You can ping anything on the remote subnet, even if it is a non-responsive IP address it still needs to open the tunnel to find out.

Edit: I guess for that matter you could also load an IP via HTTP from the remote subnet. There doesn't need to be an http server on the remote side listening. The outbound traffic to the VPN subnet will be enough. So basically you can use the http demo to request any IP address on the remote subnet to wake the tunnel.

If you wanted to loop the request until you got confirmation you could use a service on the remote subnet and look for a response. That would make it more reliable.