pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[unknownz]

running fine for me on rt-ac68u

pixelserv-tls 2.2.0-rc.4 (compiled: Sep 23 2018 19:12:30 flags: tls1_3) options: 192.168.1.2 -l 2


uts    1d 23:27    process uptime
log    2    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    14    maximum number of service threads
kvg    8.30    average number of requests per service thread
krq    764    max number of requests by one service thread
req    7721    total # of requests (HTTP, HTTPS, success, failure etc)
avg    3365 bytes    average size of requests
rmx    57430 bytes    largest size of request(s)
tav    6 ms    average processing time (per request)
tmx    5059 ms    longest processing time (per request)
slh    6453    # of accepted HTTPS requests
slm    24    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    88    # of dropped HTTPS requests (client disconnect without sending any request)
slu    1079    # of dropped HTTPS requests (other TLS handshake errors)
uca    0    slu break-down: # of unknown CA reported by clients
uce    0    slu break-down: # of unknown cert reported by clients
ush    242    slu break-down: # of shutdown by clients after ServerHello

For people on rc.4, how is your runtime/stability so far? Here is mine. Note the "tls1_3" flag that indicates I'm running the static version with support for TLS 1.3

I added a paragraph "Indicator of TLS 1.3 support on servstats page" shortly after release. Some ppl might have missed and may want to have a look..

pixelserv-tls 2.2.0-rc.4 (compiled: Sep 23 2018 19:12:30 flags: tls1_3) options: 192.168.1.3 -A 344 -l 2 -c 350

uts 2d 05:48 process uptime
log 2 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 104 maximum number of service threads
kvg 1.30 average number of requests per service thread
krq 3286 max number of requests by one service thread
req 33736 total # of requests (HTTP, HTTPS, success, failure etc)
avg 10193 bytes average size of requests
rmx 79635 bytes largest size of request(s)
tav 43 ms average processing time (per request)
tmx 9831 ms longest processing time (per request)
slh 21534 # of accepted HTTPS requests
slm 11 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 2773 # of dropped HTTPS requests (client disconnect without sending any request)
slu 2764 # of dropped HTTPS requests (other TLS handshake errors)
uca 0 slu break-down: # of unknown CA reported by clients
uce 0 slu break-down: # of unknown cert reported by clients
ush 509 slu break-down: # of shutdown by clients after ServerHello

 

[Twiglets]

kvic,
Running fine, not having any problems.

 

[joe scian]

pixelserv-tls 2.2.0-rc.4 (compiled: Sep 23 2018 19:12:30 flags: tls1_3) options: 192.168.2.3

uts 0d 16:19 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 16 maximum number of service threads
kvg 1.03 average number of requests per service thread
krq 24 max number of requests by one service thread
req 2169 total # of requests (HTTP, HTTPS, success, failure etc)
avg 542 bytes average size of requests
rmx 33166 bytes largest size of request(s)
tav 17 ms average processing time (per request)
tmx 2100 ms longest processing time (per request)
slh 46 # of accepted HTTPS requests
slm 91 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 1336 # of dropped HTTPS requests (client disconnect without sending any request)
slu 624 # of dropped HTTPS requests (other TLS handshake errors)
uca 0 slu break-down: # of unknown CA reported by clients
uce 0 slu break-down: # of unknown cert reported by clients
ush 579 slu break-down: # of shutdown by clients after ServerHello
sct 50 cert cache: # of certs in cache
sch 1966 cert cache: # of reuses of cached certs
scm 19 cert cache: # of misses to find a cert in cache
scp 6 cert cache: # of purges to give room for a new cert
sst 208 sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh 8 sess cache: # of reuses of cached TLS sessions
ssm 18 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 20 # of GET requests for server-side scripting
gif 1 # of GET requests for GIF
ico 25 # of GET requests for ICO
txt 8 # of GET requests for Javascripts
jpg 0 # of GET requests for JPG
png 0 # of GET requests for PNG
swf 0 # of GET requests for SWF
sta 14 # of GET requests for HTML stats
stt 0 # of GET requests for plain text stats
ufe 1 # of GET requests /w unknown file extension
opt 0 # of OPTIONS requests
pst 19 # of POST requests
hed 0 # of HEAD requests (HTTP 501 response)
rdr 2 # 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 8 # of unknown HTTP requests (HTTP 501 response)
tmo 12 # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls 1345 # 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)

all good here Kvic

 

[M@rco]

Everything running smooth here as well...

 

[SMS786]

For people on rc.4, how is your runtime/stability so far? Here is mine. Note the "tls1_3" flag that indicates I'm running the static version with support for TLS 1.3

I added a paragraph "Indicator of TLS 1.3 support on servstats page" shortly after release. Some ppl might have missed and may want to have a look..

Looking pretty good thus far on the trusty 68U:

pixelserv-tls 2.2.0-rc.4 (compiled: Sep 23 2018 19:12:30 flags: tls1_3)

uts    2d 08:01    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    36    maximum number of service threads
kvg    1.20    average number of requests per service thread
krq    108    max number of requests by one service thread
req    6778    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1062 bytes    average size of requests
rmx    42633 bytes    largest size of request(s)
tav    11 ms    average processing time (per request)
tmx    204 ms    longest processing time (per request)
slh    439    # of accepted HTTPS requests
slm    169    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    2467    # of dropped HTTPS requests (client disconnect without sending any request)
slu    3582    # of dropped HTTPS requests (other TLS handshake errors)
uca    0    slu break-down: # of unknown CA reported by clients
uce    0    slu break-down: # of unknown cert reported by clients
ush    2267    slu break-down: # of shutdown by clients after ServerHello
sct    50    cert cache: # of certs in cache
sch    6172    cert cache: # of reuses of cached certs
scm    74    cert cache: # of misses to find a cert in cache
scp    25    cert cache: # of purges to give room for a new cert
sst    2    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    89    sess cache: # of reuses of cached TLS sessions
ssm    75    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    284    # of GET requests for server-side scripting
gif    41    # of GET requests for GIF
ico    5    # of GET requests for ICO
txt    42    # of GET requests for Javascripts
jpg    28    # of GET requests for JPG
png    1    # of GET requests for PNG
swf    0    # of GET requests for SWF
sta    27    # of GET requests for HTML stats
stt    0    # of GET requests for plain text stats
ufe    30    # of GET requests /w unknown file extension
opt    0    # of OPTIONS requests
pst    5    # of POST requests
hed    0    # of HEAD requests (HTTP 501 response)
rdr    39    # 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    0    # of unknown HTTP requests (HTTP 501 response)
tmo    0    # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls    2526    # 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)

 

[elorimer]

For people on rc.4, how is your runtime/stability so far?

Not too good here. The no_TLS1.3 version works fine for me, but the staticly linked version doesn't. I purged my certificates and restarted, but I am getting no https connections, and most pages are hanging at "Establishing secure connection". This on an 87U at 384.5.

So I've got some puzzling to do.

 

[kvic]

Not too good here. The no_TLS1.3 version works fine for me, but the staticly linked version doesn't. I purged my certificates and restarted, but I am getting no https connections, and most pages are hanging at "Establishing secure connection". This on an 87U at 384.5.

So I've got some puzzling to do.

That sounds very weird. A couple of people had been working hard on tests in the past few days on Discord. @jrmwvu04 is pretty much in good shape now. @Protik still got "random" crash/hang. Do you want to participate in Discord?

Btw, thanks to all who responded to my calling today. Much appreciated.

 

[elorimer]

Do you want to participate in Discord?

Sure. Not familiar with it, but I am certainly game. I'm a somewhat complicated setup with Diversion, skynet, syslog-ng, some custom scripts for openvpn and what not.

 

[DonnyJohnny]

@kvic
I want to do the ad block stress test. There is a link that generate a lot of ad dns requests. I forgotten the link. Do you have that?
My pixelserv up for 1 day. Doing well. Did a few stress test but I want to make more stress to test my stubby with 3 dns server.
Currently using links from https://pi-hole.net/pages-to-test-ad-blocking-performance/ and try opening them quickly repeatly.

 

[kvic]

My pixelserv up for 1 day. Doing well. Did a few stress test but I want to make more stress to test my stubby with 3 dns server.
Currently using links from https://pi-hole.net/pages-to-test-ad-blocking-performance/ and try opening them quickly repeatly.

I don't have that link handy. I believe it's buried deep in this thread. I usually use cnn/foxnews/dailymail. Dailymail is pretty good. Stress tests are a good idea. One shot for two goals. What a good deal for you. Btw, thanks for tackling some of the questions in this thread. You should speak up more when time permitted..

 

[truglodite]

I had it running for about 2 days, and so far it is going mostly OK...

That's a grab from after I had to restart due to (what I'm guessing was) a pixelserv crash this afternoon. I discovered the crash when I kept getting time outs trying to access servstats. I also tried accessing one of the known certs using "https://googleads.g.doubleclick.net" and that also timed out. Normal web browsing appeared unaffected, though I can't say for sure if pixelserv was still doing it's thing since the pages I visited had no ads anyways. Logging in to Diversion and restarting pixelserv got things running again. I don't see any relevant logs (at log=3), other than a crap load (1200 in 20min) of these lines all at once from the same client (an iPhone w/o the self signed cert):

Sep 26 09:35:11 pixelserv-tls[1641]: handshake failed: client 192.168.XXX.XXX:59030 server graph.instagram.com. Lib(20) Func(148) Reason(1042)

There are some other different pixelserv log entries that appear after that flood, before I restarted pixelserv. So I can't say the apparent crash had anything to do with the flood. When I logged in to the router webui, nothing else looked out of whack. FWIW, I'm running the latest Merlin on an ac86u, with the latest diversion, latest skynet, and of course current pixelserv_beta. I'm also running a couple of simple scripts for ntpd and iptables to keep my security cameras from phoning home. I doubt those scripts would cause issues, but I can share them if it helps troubleshooting.

Also, if there is anything I can do to capture relevant troubleshooting data if I find pixelserv in this state again, let me know. My network isn't very busy, just a home with some 5 family members and usually no more than 20 devices connected at a time (mostly IOT devices).

 

[kvic]

A short summary of the current state on rc.4 with TLS 1.3 built-in. Some people experience a hung process or a crash. When a hung process happens, servstats page will appear loading and take a long while to timeout (e.g 26s). When it eventually timeout, a broken page is shown. When a hung process eventually crashes, very little traces in the log.

The time leading to a hung process or crash seems "random" but some people are easier to run into the issue than others. I believe it's s due to the combination of clients in your LAN environment. Hence, be observant on clients and their activities might shed some light.

So far we're talking about Entware binaries running on ASUSWRT kernel. ASUSWRT is least helpful in debugging issues like this and I believe ASUS handicapped their own developers too. If there are people having an ARMv8 SBC or x86_64 PC that could run pixelserv-tls on a daily basis, I could try to produce a debug build for you.

Personally I cannot reproduce the issue. My rc.4 is still going strong regardless how I abuse it. Hence, we might have to slow down the pace of 2.2.0 a bit until we get to the bottom of this.

 

[truglodite]

I would be happy to give a debug build a run. Of course I'm very interested in getting to the bottom of the problem (or at least as close to it as possible).

I'm not sure if I could sniff traffic from the troublesome clients, but I have a laptop with linux+wireshark and a managed switch that might be able to help. I am a rookie with wireshark though, LOL.

 

[dugaduga]

Pixelserv ip was being automatically inserted into Administration/Advanced "Remote Access Config" "Allow only specified IP address" "Specified IP address", Allow Rights for Web UI... giving it permission to connect to the Router GUI. This happened after enabling "Allow only specified IP address". I removed pixselserv's ip in case something could hijack the pid of pixelserv and use it to login. Is this normal, what is this for? Nothing appears broken with it missing.

 

[Makaveli]

For people on rc.4, how is your runtime/stability so far? Here is mine. Note the "tls1_3" flag that indicates I'm running the static version with support for TLS 1.3

I added a paragraph "Indicator of TLS 1.3 support on servstats page" shortly after release. Some ppl might have missed and may want to have a look..

So its been great for me.

pixelserv-tls 2.2.0-rc.4 (compiled: Sep 23 2018 19:12:30 flags: tls1_3) options: 192.168.1.3

uts 4d 02:04 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 6 number of active service threads
kmx 18 maximum number of service threads
kvg 1.45 average number of requests per service thread
krq 391 max number of requests by one service thread

req 19649 total # of requests (HTTP, HTTPS, success, failure etc)
avg 927 bytes average size of requests
rmx 31544 bytes largest size of request(s)
tav 1 ms average processing time (per request)
tmx 283 ms longest processing time (per request)

slh 7518 # of accepted HTTPS requests
slm 83 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 7965 # of dropped HTTPS requests (client disconnect without sending any request)
slu 3380 # of dropped HTTPS requests (other TLS handshake errors)
uca 0 slu break-down: # of unknown CA reported by clients
uce 0 slu break-down: # of unknown cert reported by clients
ush 496 slu break-down: # of shutdown by clients after ServerHello

 

[joe scian]

everything was good for a few days running tls1_3 version. Today went to run 192.168.2.3/servstats and get "waiting for 192.168.2.3".
reinstalled from command line - all OK again.

 

[M@rco]

I guess I'm having issues with v2.2.0-rc.4 tls1_3 too. I noticed several sites upon opening not loading, including pixelserv-stats. Browser seems to hang on Performing a TLS handshake with... It'll finish loading the page eventually, but it takes minutes. Restarting pixelserv-tls instantly solves the issue. For some reason it seems to have increased over the past few hours.

Anything I can do to help troubleshoot this issue? I've added '-l 4' to increase log verbosity and will see what comes up.

 

[unknownz]

guess i spoke too soon as well.

taking the cue from @M@rco, i went to check the status of pixelserv and realise that it is not working i.e. accessing the servstats page does not load. did a restart and was able to load the page.

will monitor and see if it survives uptime beyond 2 days

 

[kvic]

My rc.4 still going strong. A few pixelserv ninjas have been working hard in the past few days to reproduce the issue.

We already have a much better understanding what’s the issue. A fix might not be possible as it’s related to very new feature in tls 1.3. I still have to look into it. A workaround should be easy.

For ppl with access to Discord troubleshooting steps and full discussions are there.

I personally caught a cold. Hence delayed the update in this thread.

Luckily we didn’t have to go the route of firing up a PC. It takes longer time and a few more hassle but we got there on Asus routers.

 

[M@rco]

Thanks for the update @kvic. I hope you feel better soon!