Just as an FYI....with the debian patch applied on my fork, I don't see any difference in memory use (running one VPN Server, one VPN Client, NOT running ABSolution/pixelserv)
Can you see what impact it has on openssl speed?
Just as an FYI....with the debian patch applied on my fork, I don't see any difference in memory use (running one VPN Server, one VPN Client, NOT running ABSolution/pixelserv)
Can you see what impact it has on openssl speed?
Zero from my tests.
btw unrelated this change. It used to be FW openssl speed faster than Entware. Now it's the other way round. But my FW version is 380.66. So probably not fair comparison.
I just changed my dns server from cloudflare to Google and I see that it affect the uce. I have no issue with uca but during my usage of cloudflare doh, the uce number will go up occasionally. When Changed to Google doh, it remain 0. There are still small number of slu but i think is small issue.I can see my reply to you. This thread is getting busier.. easy to lose track.. even for myself but after v2.1 release it shall go quieter I believe.
A few subsequent discussions also apply to your situation.
I'm interested in hearing back from people trying two instances of pixelserv-tls (either for load balancing or two IP approach for filtering known "unknown cert" servers).
A way to test tav
A stripped down version of test in #1618. Set to "-O 5" and restart pixelserv-tls.
Browse website_1, wait for 6 seconds, browse webiste_2, wait for 6s and repeat.
website 1 & 2 could be foxnews and cnn.com. This shall provide a worst scenario tav (for a potential issue I could think of).
I'm also going to do some comparison between rc.3 and rc.4 (both using the new lib) later today.
tav (old lib) tav (new lib)
rc.3 8ms 7ms
rc.4 8ms 7ms
I just changed my dns server from cloudflare to Google and I see that it affect the uce. I have no issue with uca but during my usage of cloudflare doh, the uce number will go up occasionally. When Changed to Google doh, it remain 0. There are still small number of slu but i think is small issue.
Site I used for testing
https://pi-hole.net/pages-to-test-ad-blocking-performance/
Question, those choice of dns affect this?
Using rc4 and rebuilted OpenSSL lib
Seems to me you're over thinking here.
When you manually override browser warning (and if it actually allow you to do it), then from TLS handshake perspective, no difference to having your Pixelserv CA installed.
iOS 8...I don't have a device to test. Seems to me more like an OS issue though
tested websites
foxnews.com (first four sections - click on each as one website in above description)
cnn.com (first four sections - ditto)
dailymail.co.uk (first four sections - ditto)
Other procedures and settings are described as above.
Results
Code:tav (old lib) tav (new lib) rc.3 8ms 7ms rc.4 8ms 7ms
Surprise (!!) new lib is faster (by 12.5%) for pixelserv-tls in the above described workload pattern.
I repeated a few times for each case. The results are consistently reproducible.
(Note that...the improved cert cache lookup in rc.4 doesn't have chance to perform in this test 'cos we don't fill up the cache)
edit:
single instance of pixelserv-tls running on 1.2GHz RT-AC56.
It's possible that Entware eventually picked most of the optimizations I've made over the years (switching to -O3 for instance - the upgrade from 1.0.0 to 1.0.2 also leveraged much more optimized ASM code for AES/SHA). Might be worth I had another look at their build recipe for it, in case there might be further optimizations I could pick up.
I wonder too if they wouldn't be gaining some more performance by using glibc instead of the antique uclibc used by pre-HND Asuswrt.
# pixelserv-tls -B
CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
1. generate cert to disk: 51.049 ms load from disk: 4.848 ms
2. generate cert to disk: 39.019 ms load from disk: 5.251 ms
3. generate cert to disk: 50.609 ms load from disk: 5.494 ms
4. generate cert to disk: 65.390 ms load from disk: 5.211 ms
5. generate cert to disk: 66.189 ms load from disk: 4.798 ms
6. generate cert to disk: 46.024 ms load from disk: 4.802 ms
7. generate cert to disk: 77.728 ms load from disk: 4.785 ms
8. generate cert to disk: 46.584 ms load from disk: 4.833 ms
9. generate cert to disk: 70.946 ms load from disk: 4.798 ms
10. generate cert to disk: 59.312 ms load from disk: 4.796 ms
generate to disk average: 57.285 ms
load from disk average: 4.962 ms
pixelserv-tls 2.1.0-rc.4 (compiled: Apr 5 2018 21:02:10 flags: tfo) options: 192.168.1.2 -l 2
uts 0d 08:58 process uptime
log 2 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 92 number of active service threads
kmx 105 maximum number of service threads
kvg 20.56 average number of requests per service thread
krq 88938 max number of requests by one service thread
req 110110 total # of requests (HTTP, HTTPS, success, failure etc)
avg 546 bytes average size of requests
rmx 35869 bytes largest size of request(s)
tav 3 ms average processing time (per request)
tmx 5357 ms longest processing time (per request)
slh 107294 # of accepted HTTPS requests
slm 55 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 1104 # of dropped HTTPS requests (client disconnect without sending any request)
slu 9 # of dropped HTTPS requests (other TLS handshake errors)
uca 0 slu break-down: # of unknown CA reported by clients
uce 8 slu break-down: # of unknown cert reported by clients
sct 50 cert cache: # of certs in cache
sch 1560 cert cache: # of reuses of cached certs
scm 278 cert cache: # of misses to find a cert in cache
scp 265 cert cache: # of purges to give room for a new cert
sst 3 sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh 605 sess cache: # of reuses of cached TLS sessions
ssm 1169 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 905 # of GET requests for server-side scripting
gif 29 # of GET requests for GIF
ico 25 # of GET requests for ICO
txt 104785 # of GET requests for Javascripts
jpg 80 # of GET requests for JPG
png 21 # of GET requests for PNG
swf 0 # of GET requests for SWF
sta 26 # of GET requests for HTML stats
stt 0 # of GET requests for plain text stats
ufe 45 # of GET requests /w unknown file extension
opt 0 # of OPTIONS requests
pst 275 # of POST requests
hed 0 # of HEAD requests (HTTP 501 response)
rdr 1562 # 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 31 # of unknown HTTP requests (HTTP 501 response)
tmo 773 # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls 1490 # 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)
Very happy with this!
htop shows 1.9% mem used (9.7Mb of 512Mb on AC86U)!!!
tav. slu / req, uce, kcc all good with rc.4 and new lib
And your instructions to remove "handshake error: unknown cert" entries in syslog and these stats.
pixelserv-tls 2.1.0-rc.4 (compiled: Apr 5 2018 21:02:08) options: 192.168.2.2 -c 150 -l 2
uts 1d 14:05 process uptime
log 2 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 26 maximum number of service threads
kvg 1.34 average number of requests per service thread
krq 45 max number of requests by one service thread
req 2852 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1326 bytes average size of requests
rmx 62993 bytes largest size of request(s)
tav 38 ms average processing time (per request)
tmx 2933 ms longest processing time (per request)
slh 881 # of accepted HTTPS requests
slm 1 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 635 # of dropped HTTPS requests (client disconnect without sending any request)
slu 1274 # of dropped HTTPS requests (other TLS handshake errors)
uca 133 slu break-down: # of unknown CA reported by clients
uce 114 slu break-down: # of unknown cert reported by clients
After 1day 14hours, using 1% of 250MB.
Not saying that -03 is bad, just needs comprehensive testing before things go out as production level code.
Check the AB-Solution thread. A week or two back, @thelonelycoder added several additional whitelist entries to resolve SNB Forums ad issues. These entries also resolve Amazon Android app access.Hello,
I have a question, When i turn pixelserv-tls on in AB-Solution, I'm getting error on my Amazon Android Apps the Oops message, someone know how to fix this?
Thanks
Thread starter | Title | Forum | Replies | Date |
---|---|---|---|---|
C | Diversion Pixelserv replacement | Asuswrt-Merlin AddOns | 2 | |
L | Is Diversion better than NextDNS, PiHole or AdGuard Home? | Asuswrt-Merlin AddOns | 10 |
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!