ERR_CONNECTION_REFUSED on Chrome using an RC4000 as web server

Hi All,

I have a problem on the field with the RCM4000 board. I developed an application that implements the web server and the snmp functionalities. Both protocols works fine for a while, but after some days, the web server do not allows the access to the web page. The response on Chrome browser is ERR_CONNECTION_REFUSED.

It’s strange, because the SNMP continues to work and the module responds to ping requests. I’m using the following code to set permissions

uid = sauth_adduser(“user”, “password”, SERVER_HTTP);
sauth_setusermask(uid, USER_GROUP, NULL);

When the module is switched off and restarted the web page retuns to works

Thank you in advance

1 Like

What Dynamic C version are you running?
Please make sure you are running the latest software.

The latest can be found in the github, download latest zip file.

You could try increasing HTTP_MAXSERVERS, which will allow for more simultaneous connections. And make sure you call tcp_reserveport(80) in your program startup, that will queue connections while your program services requests.

Note that if you’re using SSL/TLS (for https), you’ll want the latest Dynamic C (10.72C from the website) since it supports TLS 1.2 (which is likely required by Chrome at this point) and other TLS-related features.

If you want the cutting edge version, download from the GitHub URL in Campbell’s answer.

Hi All and thanks for response.

I’m already using the DC10.72, the HTTP_MAXSERVERS are set to 2 and i already calling tcp_reserveport(IPConfig.HttpPort);

This is the main server task (i’m using uC/OS-II).

void serverRun()
IpConfig_handler(); // polling network config
http_handler(); // polling Http
ftp_tick(); // polling Ftp

is it possible i’ve to call http_handler() in a dedicated task? There is a way to check if the http socket is down in order to restart it?

Increase HTTP_MAXSERVERS to at least 4 and see if that helps. I don’t think you need to call tcp_tick(NULL) in that task, since both the http and ftp handlers are probably calling it, but it isn’t hurting anything. It looks like you’re keeping all TCP/IP-related calls in one task (which is good) and hopefully with a 4KB stack.