I've notified Entware gents. But not sure if they'll be able to provide test library. I'll be able to offer armv7 (perhaps armv8 and mipsel) for tests.
The rebuild will be fully compatible with existing software.
pixelserv pixelserv - A Better One-pixel Webserver for Adblock
- Thread starter kvic
- Start date
I've notified Entware gents. But not sure if they'll be able to provide test library. I'll be able to offer armv7 (perhaps armv8 and mipsel) for tests.
The rebuild will be fully compatible with existing software.
visortgw
Part of the Furniture
arm7 works for me (RT-AC68U) -- I'd be more than willing to test.
Thanks for your trust. Appreciate it.
It's still possible that we may get test library directly from Entware.
Butterfly Bones
Very Senior Member
I'm willing to test arm8 if it will help.
I'm busy compiling stats right now, going on day 3 with some interesting observations I'll share later. (this place needs a thumbsup emoji
)
I'm busy compiling stats right now, going on day 3 with some interesting observations I'll share later. (this place needs a thumbsup emoji
)I don't want you to take this the wrong way, because I am a great admirer of your work, and the current speed and memory footprint of pixelserv-tls is so fully acceptable to me that this next step I put in the separate category of pointing a way to others to improve entware and openssl. At the same time, my own ignorance of entware and openssl is so complete that I am dependent on the open source model to protect me.
So I hope you will understand that I am reluctant to install any rebuild of these crypto modules outside of the larger open source community. That is partly because I don't want to compromise updates from that channel that address other vulnerabilities.
My hope is that braver souls will demonstrate an improvement you offer that the larger channel takes up. For me, too far a step, and I hope you might leave open releasing a 2.1 version and leave this for a 2.2 version that uses updates from the openssl/entware channel.
Also, on my 87U, with 3.3% memory usage, here are my stats, and ain't no complainin':
Code:
uts 3d 11:00 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 40 maximum number of service threads
kvg 2.64 average number of requests per service thread
krq 89 max number of requests by one service thread
req 6956 total # of requests (HTTP, HTTPS, success, failure etc)
avg 605 bytes average size of requests
rmx 18435 bytes largest size of request(s)
tav 30 ms average processing time (per request)
tmx 1761 ms longest processing time (per request)
slh 5383 # of accepted HTTPS requests
slm 1 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 85 # of dropped HTTPS requests (client disconnect without sending any request)
slu 399 # of dropped HTTPS requests (other TLS handshake errors)
sct 100 cert cache: # of certs in cache
sch 3921 cert cache: # of reuses of cached certs
scm 31 cert cache: # of misses to find a cert in cache
scp 6 cert cache: # of purges to give room for a new cert
sst 0 sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh 68 sess cache: # of reuses of cached TLS sessions
ssm 319 sess cache: # of misses to find a TLS session in cache
ssp 0 sess cache: # of purges to give room for a new TLS session
Last edited:
I had the impression you're an 'expert' user. This lousy attitude is not acceptable.
People won't even get the link to download from me if they don't express willingness to test the rebuild of openssl library.
When I commented about availability of test library from Entware, frankly I was only thinking on the variable of time. Re-reading my words again, I can't blame your interpretation.
You presumed a bit too much. A rebuild usually means zero or very little change in code. When a new version/build comes out, users install over it. They simply lose the benefit of the previous rebuild.
You completely misunderstood the situation. pixelserv-tls will stay the same. The openssl library requires a rebuild. So there is no v2.1 or v2.2 to begin with regarding this.
Users run the rebuild of the openssl library, take the benefit of using less memory. If they don't, they stay the same which could be as happy as you or as unhappy as I'm after seeing memory usage on some of people's feedback.
Good stuff requires repetition regardless how silly I may sound. One motto I learned from this forum. So here we go. After 12 hours:
Process ID's same as before (post #1662). The latest build of pixelserv-tls with rebuild of openssl is hovering around 5MB. Sweet!
To re-iterate, the work done in rc.3 is in effect and truly showing its color in terms of memory efficiency.
With the stock openssl library, the excessively abuse of RAM use offsets my best effort trying to contain it in rc.3. Now with the rebuild library the effort gets the chance to show its color.
Protik
Senior Member
Ok, I know the test libraries from Entware are ready. Thanks to @zyxmon.
For veteran Entware users, you probably could spot where to get it, and experience a difference on rc.3. Or else everyone could wait a bit for instructions.
2.1.0-rc.4 is also going to be released in 6 hours.
p.s. @ryzhov_al, I added you both in a conversation but snbforum didn't let me send. So I had to exclude you to get it sent..
For veteran Entware users, you probably could spot where to get it, and experience a difference on rc.3. Or else everyone could wait a bit for instructions.
2.1.0-rc.4 is also going to be released in 6 hours.
p.s. @ryzhov_al, I added you both in a conversation but snbforum didn't let me send. So I had to exclude you to get it sent..
If I follow, you propose compiling the OpenSSL library to not use its own memory allocation function. This because its scheme uses more memory than is optimal on a small router. I had the impression that a lot of attention had been given to issues in this scheme because of Heartbleed (itself introduced by the scheme); do we end up with a similar level of protection now?
Also, thanks for the explanation. I'm much more comfortable with a compile option than changing a library function.
Also, thanks for the explanation. I'm much more comfortable with a compile option than changing a library function.
Can you pls backup your claim with code evidence?
I also suggest you post this question for the experts in openssl mailing list.
I'm no kind of expert to even make a stab at it. I was reading https://blogs.akamai.com/2014/04/heartbleed-update.html, the update, and the code example akamai contributed. I don't know if that went anywhere.
Also here, if you don't mind the security warning: https://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
This is where I get the idea that putting the no_buf_freelist option into config, you don't use the openssl malloc process, but something else.
PS: I wonder if it is malloc that is the source of the odd -c98 vs -c100 behaviour you noticed?
Also here, if you don't mind the security warning: https://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
This is where I get the idea that putting the no_buf_freelist option into config, you don't use the openssl malloc process, but something else.
PS: I wonder if it is malloc that is the source of the odd -c98 vs -c100 behaviour you noticed?
Technically I think we have no further to discuss. Nor in my interest to convince you in any way.
For the benefit of doubt, I would put release on hold temporarily.
I would suggest you post the question of that flag to openssl mailing list. To get some sort of assurance. For the good of us all.
Perhaps I should have done it earlier.
I downloaded Debian Jessie source deb package. Turns out Debian enabled this flag. No wonder I saw solid memory usage on Intel.
@elorimer Maybe this can save us some hassle?
I downloaded Debian Jessie source deb package. Turns out Debian enabled this flag. No wonder I saw solid memory usage on Intel.
Code:
$ cat disable_freelist.patch
From: Kurt Roeckx <[email protected]>
Subject: Disable the freelist
We don't define OPENSSL_NO_BUF_FREELISTS globally sinc it changes structures and
would break the ABI. Instead we just do it in the .c files that try to do
something with it.
Index: openssl-1.0.2/ssl/s3_both.c
===================================================================
--- openssl-1.0.2.orig/ssl/s3_both.c
+++ openssl-1.0.2/ssl/s3_both.c
@@ -573,6 +573,7 @@ int ssl_verify_alarm_type(long type)
return (al);
}
+#define OPENSSL_NO_BUF_FREELISTS
#ifndef OPENSSL_NO_BUF_FREELISTS
/*-
* On some platforms, malloc() performance is bad enough that you can't just
Index: openssl-1.0.2/ssl/ssl_lib.c
===================================================================
--- openssl-1.0.2.orig/ssl/ssl_lib.c
+++ openssl-1.0.2/ssl/ssl_lib.c
@@ -162,6 +162,8 @@
const char *SSL_version_str = OPENSSL_VERSION_TEXT;
+#define OPENSSL_NO_BUF_FREELISTS
+
SSL3_ENC_METHOD ssl3_undef_enc_method = {
/*
* evil casts, but these functions are only called if there's a library@elorimer Maybe this can save us some hassle?
Ah, I see I have indeed offended you. Please accept my apologies. It was never my intent.
No apologies required. I've gone through such burden of proof in my work life too many times.
Indeed I shall have pulled the Debian source to cut the conversation short. But at the same time not enough thinking for rest of us to go through. I think it's about right.
Thanks for all the questions! I think it's good to have you in open source. lol
Code:
pixelserv-tls 2.1.0-rc.3 (compiled: Mar 30 2018 17:10:59) options: 192.168.10.3
uts 0d 23:17 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 2 number of active service threads
kmx 12 maximum number of service threads
kvg 1.08 average number of requests per service thread
krq 9 max number of requests by one service thread
req 8053 total # of requests (HTTP, HTTPS, success, failure etc)
avg 926 bytes average size of requests
rmx 4703 bytes largest size of request(s)
tav 0 ms average processing time (per request)
tmx 69 ms longest processing time (per request)
slh 2176 # of accepted HTTPS requests
slm 17 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 1359 # of dropped HTTPS requests (client disconnect without sending any request)
slu 4392 # of dropped HTTPS requests (other TLS handshake errors)
sct 77 cert cache: # of certs in cache
sch 4921 cert cache: # of reuses of cached certs
scm 77 cert cache: # of misses to find a cert in cache
scp 0 cert cache: # of purges to give room for a new cert
sst 0 sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh 201 sess cache: # of reuses of cached TLS sessions
ssm 143 sess cache: # of misses to find a TLS session in cache
ssp 0 sess cache: # of purges to give room for a new TLS session
nfe 2180 # of GET requests for server-side scripting
gif 0 # of GET requests for GIF
ico 0 # of GET requests for ICO
txt 25 # of GET requests for Javascripts
jpg 0 # of GET requests for JPG
png 2 # of GET requests for PNG
swf 0 # of GET requests for SWF
sta 3 # of GET requests for HTML stats
stt 0 # of GET requests for plain text stats
ufe 19 # of GET requests /w unknown file extension
opt 0 # of OPTIONS requests
pst 34 # of POST requests
hed 0 # of HEAD requests (HTTP 501 response)
rdr 6 # of GET requests resulted in REDIRECT response
nou 0 # of GET requests /w empty URL
pth 0 # of GET requests /w malformed URL
204 0 # of GET requests (HTTP 204 response)
bad 4 # of unknown HTTP requests (HTTP 501 response)
tmo 10 # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls 1362 # of dropped requests (client disconnect without sending any request)
cly 0 # of dropped requests (client disconnect before response sent)
clt 0 # of dropped requests (reached maximum service threads)
err 0 # of dropped requests (unknown reason)
Last edited:
For people posted servstats in the past few days that I haven't responded individually, thanks to your feedback. All read and appropriate action taken e.g. getting to the bottom of memory usage.
@punkinduster I got your post in email (not always happen on snbforum system btw..) but could longer find it to respond in the thread... I didn't get chance to test the libraries myself yesterday nor finish preparation for rc.4. Will do it today in 12 hours or so.
If people want to give a try on the libraries, here you're:
armv8 64-bit: http://bin.entware.net/aarch64-k3.10/test/
armv7: http://bin.entware.net/armv7sf-k2.6/test/
You only have to override the "libopenssl" ipk.
@punkinduster I got your post in email (not always happen on snbforum system btw..) but could longer find it to respond in the thread... I didn't get chance to test the libraries myself yesterday nor finish preparation for rc.4. Will do it today in 12 hours or so.
If people want to give a try on the libraries, here you're:
armv8 64-bit: http://bin.entware.net/aarch64-k3.10/test/
armv7: http://bin.entware.net/armv7sf-k2.6/test/
You only have to override the "libopenssl" ipk.
