MQX 4 - HTTPSRV : sockets stay opened

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MQX 4 - HTTPSRV : sockets stay opened

3,663 Views
yb
Contributor IV

Hello,

I use MQX 4.0.2.2 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 !

Regards,

Yvan

Tags (3)
14 Replies

1,948 Views
eugeneryabtsev
Contributor III

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:

long-delay.png

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:

number-of-connections.png

1,948 Views
thiagow
Contributor III

I have the same problem of Regis, but I don't need to press F5 several times. When I boot my board and it's working for 48 hours the problem starts. Sometimes the css, png or javascript files are'nt loaded on page.

Does anybody could correct this problem?

0 Kudos

1,948 Views
lfschrickte
Contributor IV

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!

Thank you

Luiz Fernando

0 Kudos

1,948 Views
r_letourneur
Contributor III

Hi Luiz,

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?
Regards

0 Kudos

1,948 Views
thiagow
Contributor III

I have the same problem of Regis, but I don't need to press F5 several times. When I boot my board and it's working for 48 hours the problem starts. Sometimes the css, png or javascript files are'nt loaded on page.

Does anybody could correct this problem?

0 Kudos

1,948 Views
lfschrickte
Contributor IV

Thiago,

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

char rtcs_mem_pool[51200];

void network_manager_init(void)

{

....

....

  /* 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!

Regards =)

1,948 Views
thiagow
Contributor III

Thanks, it looks that using _RTCSPCB_init = 10;  and increasing max sessions on http task to 6 decrease the times that the problem occours.

0 Kudos

1,948 Views
lfschrickte
Contributor IV

Hi Regis,

Yes, I'm running it without problems!

Two questions:

- 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!

Regards

Luiz Fernando

0 Kudos

1,948 Views
r_letourneur
Contributor III

Hi Luiz,

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?
Regards

0 Kudos

1,948 Views
lfschrickte
Contributor IV

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.

Regards

0 Kudos

1,948 Views
r_letourneur
Contributor III

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.

Regards

0 Kudos

1,948 Views
karelm_
Contributor IV
0 Kudos

1,948 Views
karelm_
Contributor IV

Hi,

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.

Best regards,

Karel

0 Kudos

1,948 Views
yb
Contributor IV

Karel,

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 4.0.2.2 and 4.1 without any doc...

Yvan

0 Kudos