I use MQX 188.8.131.52 with HTTPSRV.
When I access it slowly (normal use), all is ok. But when I keep my finger on the keyboard F5 key on my browser, the HTTPSRV becomes blocked.
Then, I pause the debugger, and I can see that sessions are closed (in the tasks list) but sockets are stay opened (the number of opened sockets is the same as HTTPSRVCFG_DEF_SES_CNT).
These sockets will be never closed...even after a very long time.
With more sessions, the problem is the same, with more sockets opened.
For information :
- the webpage is a no frame page
- I tried different parameters (keep alive, number of session, blocks size, socket options : OPT_SEND_NOWAIT, OPT_RECEVE_NOWAIT,OPT_RECEIVE_TIMEOUT, OPT_KEEPALIVE...)
I'm trying to resolve this problem for more than one week at this moment :-(
Help is needed !
I am mot sure if I have exactly the same issue, but at least it's vey similar and related. I use MQX 4.1.1, build and start httpsrv example project for Vybrid, open the browser and go to http://192.168.1.202/tcpstat.html - so far so good. Then I hit refresh button and see something like this:
After some testing, I discovered this is the behavior with Google Chrome 38 and IE 11, but not with Firefox 31. Wireshark shows that indeed the browser's behavior is different. Namely, Chrome has a preconnect feature which opens connections and then FORGETS ABOUT THEM until it needs them or 10 seconds expire. Combined with the fact that RTCS seems to ACK all incoming connections (???) above and beyond the limit (tested with "_RTCS_socket_part_max = 2", same with "_RTCSPCB_max = 2"), but httpsrv may not have enough "params[i].max_ses = 1" configured to handle them all at the same time while Chrome may choose any... a pretty solid DoS attack.
I'd like the connections rejected if nothing can be done with them anyway or the situation solved some other way from RTCS side if at all possible. Alternatively, I might allow more sessions and hope that not many Chrome browsers attempt to bother my device at any given moment, but I would prefer to waste less RAM. Doing anything browser-side seems hopeless (the issue's years old).
P.S. Can anybody briefly explain me this "Open Connections" number, especially with relation to other numbers, and what resources, exactly, are consumed when it grows:
Does anybody could correct this problem?
Same problem here.
FRDM-K64F board + MQX RTOS 4.1 + httpsrv sample
To establish a common setup is simple: in the httpsrv sample, which comes with latest MQX RTOS, the bug happens (just press Ctrl+F5 repeatedly in a page or keep clicking on some of the links). Figured out until now that higher Keep Alive timeouts are linked to more usual freezings. If Keep Alive is kept low, it is harder to make the board stop. Unfortunately for my application I need a high Keep Alive value :smileysad:
I've also noted here that the server stops if I define a stack value different from 0 in a cgi script and call this cgi script repeatedly with keep-alive on (F5 strategy). That means that if the cgi execution takes place in the caller thread it works OK - but if a separated internal task is created for each cgi script something bad happens (even if F5 is not pressed fastly - the bad combination is separated task CGI + keep alive).
Any help would be appreciated!
I'm working on FRDM-K64F board + MQX RTOS 4.1 and have the same kind of problem on my Httpsrv. When I run my server app a few minutes or secondes and I press F5 to refresh my web pages, the web pages are not displayed correctly (all is wrong mainly, css or js files in the other directories aren't displayed). The httpsrv seems to be wrong but I can't find where! The old MQX version with http_server was ok on my TWR-K60 but I can't go on it, I need more memory now. This last Httpsrv version is not stable. So I have tried the post : To file httpsrv_task.c in folder rtcs\source\apps\httpsrv_task.c to line 455 without anything change!
I'm surprised to see that this patch has resolved your problem. Are you running today your httpsrv app target on MQX?
Does anybody could correct this problem?
I'm running my device for several months without any problem - it is even serving pages well on IE. I'm using MQX 4.2 (take care with MFS implementation on this version - it has a lot of bugs - there are specific threads in this forum to address them).
One advice I can give you is to look to how many TCP connections you're allowing on your RTCS.I'm using the following parms (just a reference - I'm using sockets for other things too, not only to the http server):
|RTCS PCB and socket parms|
/* Init RTCS */
_RTCSPCB_init = 10;
_RTCSPCB_grow = 2;
_RTCSPCB_max = 16;
_RTCS_socket_part_init = 8;
_RTCS_socket_part_grow = 2;
_RTCS_socket_part_max = 14;
/* use private memory pool to avoid possible security issues */
_RTCS_mem_pool = _mem_create_pool(rtcs_mem_pool, sizeof(rtcs_mem_pool));
_RTCSTASK_stacksize = 5000;
I had issues serving pages to IE (Firefox and Chrome were working fine). I've fixed this issue by setting max sessions parameter (params.max_ses) to 6 on httpd - because IE can open 6 connections at once and the HTTP server must be ready to answer on any of them (IE opens 6 sockets but doesn't make requisitions on all of them - so if you have, for instance, max sessions set to 2 and on a request IE decides to make the first request on any of the other 4 connections you are in trouble).
You may also check through MQX debugging tools if you have enough memory for your RTCS stack - sometimes it is a good idea to allocate a dedicated memory pool as I did on the code above! This looks a good problem candidate in your case considering that you have the problem only after 48 hours - this problem can also be a hint to a memory leak in your program - in this case I suggest you to use the MQX debugging tools to check your memory allocation as well!
Just guesses - I hope at least one of them may help!
Yes, I'm running it without problems!
- Are you having problems with regular static web pages or only when running CGI scripts?
- Can you run the FRDM-K64F httpsrv example without problems after that change in the httpsrv_task.c ? Does it show the same problem? (considering the sample code untouched).
The httpsrv examples runs smoothly here after that modification. In my own application I had to be careful about the task priorities (server and script) in order to have the webserver more responsive.
Other thing worth mention, althought it is probably not your problem: did you remember to recompile rtcs and bsp? Sometimes I forget to do it and get problems because of that!
All my web pages run CGI scripts. So I remember just to recompile only rtcs. The httpsrv_task.c in folder rtcs\source\apps\httpsrv_task.c concern only rtcs not bsp. My webserver is very responsive the task priorities seems to be ok. Do you run your web app pages from uSD card?
Sorry for late reply, I thought I've already answered, my fault! Have you already solved your problem?
Yes, I can run the httpsrv both from the uSD card and from the TFS, and it runs just fine!
If I'm running too many tasks in my program sometimes I get this behavior (some content doesn't load on web pages). Don't know if it is related to your problem, just saying.
Did you already check the packets with Wireshark? Maybe Google Chrome's developer tools can help too.
Hi Luiz, my problem isn't solved! I use FireBug plugin in my firefox browser it is much powerfull than the firebug plugin on Chrome it is very usefull!. So I have different directories with css, js files contains. When the webserver crash, often firebug tell me css or js files are aborted! The html code is going on to work but css and/or js files are aborted may be the reason is webserver has lost the css and js path files, after that all my web pages are wrong with bad presentation for css and without some contains caused by js missing.
can you please write me which board/processor you use? Also if you can, please try to reproduce it in MQX 4.1. I tried to reproduce this issue but I was not able to.
I use a custom board derivated from TWRK60 + AR4100 (WiFi access). I had no problem like this with previously HTTPD version.
I'm porting the project on 4.1 since yesterday, but hard on the AR4100 side, because there are a lot of changes between 184.108.40.206 and 4.1 without any doc...