Home/Support/Support Forum/Issue with HTTP hanging up and can only recover after a reset
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Issue with HTTP hanging up and can only recover after a reset

+1 vote
We have been using Dynamic C 9 for several years and a issue has been discovered at one of the sites where HTTP is being used to serve a web page over the Internet. The issue is sometimes when a web page is accessed, the web pages fails to load and appears to remain attempting to load for some time. I've watched the loading icon for over 15 minutes while the page is trying to load before canceling. The big issue is that once this occurs, any other browser gets the same results. Not only from local computers on the network but cell phones as well.

Looking for any assistance that can be provided.
asked Jun 26, 2018 in Rabbit Software by kenhx New to the Community (1 point)

Please log in or register to answer this question.

1 Answer

0 votes
Can you provide some more details?

Can you confirm that you're using Dynamic C 9.62?

How long has the program been running when this starts to happen?

Are you using costates or uC/OS-II?

Can you reproduce the failure with one of the sample programs?

It sounds like a socket for the web server gets stuck in an open state, and the Rabbit isn't able to service any requests after that point. It's hard to say what leads to that situation -- you would need to get a packet capture using Wireshark to see what the last good connection looks like.

A simple solution might be to just set an inactivity timeout for all sockets:

// time out inactive connections after 60 seconds
tcp_config(INACTIVE, 60);

Put that in your program after calling sock_init().
answered Jun 26, 2018 by TomCollins Veteran of the Digi Community (1,368 points)
To answer your questions:

We have been using the RCM2260 Rabbit Module with Dynamic C 9.52 for a number of years.  The product with the issue has been in the field for more than 10 years.  Only one installation is showing the issue.

I'm not sure how long the program has been running before the issue occurs.  The information from the customer with the issue indicates the device will run for a couple of days then locks up.

We have not been able to recreate this issue on the bench.  Nor have we had any issues from other customers about this issue.  We have at least a dozen customers using similar setups.    

We are using costates throughout our device.  

We can't reproduce the issue on the bench using the same hardware and software.  We have not tried with the sample programs?


Some more information about the issue:

1. When we make a connection using any browser the browser will sit for 15 minutes or more showing the updating animation. In all cases we have never gotten a time out message on the browser and ended up canceling the page.

2. Refreshing or using a different browser/computer has the same results. Once the issue has occurred it takes a power up reset for the Rabbit processor to recover.

3. The issue seems to be random and will server web pages correctly for hours or days before reoccurring.

4.We have already tried swapping out hardware twice so we know it is most likely not a hardware issue.

5. Our device supports FTP and TCP/IP Modbus as well as serving web pages. Neither of these features seem affected. Even when serving web pages as stopped, FTP and TCP/IP Modbus continues for function normally.

6.The issues have only occurred in the field to a device connected to the Internet via a cell modem. We have been unable to duplicate the issue on the bench. Also, no other site using the same cell modem and device has ever exhibited this issue.

7.We used WireShark to capture the traffic between the remote device and a local computer. What we found is the remote device is returning a “ZeroWindow” just after a TCP connection has been made.
On the tcp_config(INACTIVE, 60) function, does it work only on inactive connections.  We also use TCP/IP Modbus which is a continuous connection and we can't have the connection breaking every 60 seconds.
From reviewing the code, it appears that it will only break the connection if there isn't any activity for 60 seconds.
Did this ultimately resolve your issue?
...