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
Alessandro
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.
https://github.com/digidotcom/DCRabbit_10
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
tcp_tick(NULL);
}
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.