We've got 90+ CR850s deployed around the state. I'm using Loggernet 4.2.0.22 and DevConfig 2.09.26. We've got Maxon MM6280 modems with static IP accessed via 2 sub domains behind the firewall of our VPN. The modem is hardwired on COM1 (G,C1,C2). In the last 3 months we've had issues of telemetry communications failing. As the IP is assigned to the modem and not the logger, I can still ping the modem and receive a valid response, but comms to the logger stops. Direct cable connection via the RS232 port also fails. Exchanging a few emails with our local CSA office suggested this possible scenario:
____________________________________________________________
We have recently run into a rash of data loggers that are out in the field that have become unresponsive. They are usually tied to Raven modems using the PPP mode. Typical symptoms include the data logger becoming unresponsive after some time, but the modem is still reachable via Ace Manager or Sierra Wireless’ web interface. If the data logger is still responsive, you will see a number larger than 3,270 in CommsMemFree(3) in the status table.
A simple reset (power cycle) of the data logger will return the logger to its normal running condition, but does not resolve the issue.
There is a bug in OS 27.04 and older where the telnet port, after it receives a ‘T’ or ‘t’ command (from any Ethernet port, including PPP), the logger processes it, but frees the allocated memory for that packet twice and then reinsert the packets back into the queue. So memory is never really freed and the logger continues to allocate memory for the additional packet. After a while, the memory demand becomes so large that the logger will no longer communicate but not to the point that it will watchdog.
This bug does not exist in the current OS 28 betas (27.2014.??.??.??) or in what will be OS 1 for the CR6 and OS 28 for the CR1000/CR8X0/CR3000.
Our recommendation to customers having this issue is to disable the telnet port on the data logger. This can be done by unchecking the check box next to Telnet Enabled under the Network Services Tab in Device Configuration Utility.
We also recommend an upgrade to OS 27.04 if they have not done so, but this is not required to resolve the issue.
------------------------------------------------------------
Although some of our symptoms are similar, our problem goes further. A power reset usually solves the problem for a while, although any telemetry traffic more intense than a simple data download is likely to make the logger hang again. I've tried upgrading to OS 27.04 and disabling Telnet, this seems to lengthen the time to failure, but does not stop it. In our case, CommsMemFree(3) in the status table =0. As some of our sites require a 5 hour drive or expensive helicopter flight, I'd like to find a permanent solution rather than a temporary respite after a power reset. If anyone has experienced similar issues, I'd love to hear about solutions.
Cheers,
Mick.
The recently discovered memory issue with telnet is resolved by disabling telnet. Since you disabled telnet and still lose communications, this must be a separate issue.
Another possible cause for running out of Comms Mem is if the datalogger makes TCP connections without ever closing them. If your datalogger program uses TCPOpen or HTTPGet, it should follow up later with a TCPClose.
PPP connections are most thoroughly tested on the RS232 and CSIO ports. You might be running into a bug with PPP on Com1 that existed for years but hadn't affected anyone else.
Please work with the local office in Australia to test the OS 28 beta on one of your nearby stations. OS 28 is nearing completion and uses a different IP stack than OS 27.
If CommsMemFree(3) = 0 then the IP stack is not initialized and therefore disabling Telnet should have no effect. In other words it does not sound like you are using PPP. This seems in line with "As the IP is assigned to the modem and not the logger".