pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[pattiri]

Very good!

Looking at the logs, I can't tell what led to the crash. I need some reproducible steps. e.g what websites that you visited right before leading to the crash.

Perhaps you shall try to reproduce the crash when you get time. thanks

edit:

looking closer at the log, I suspect the POST request to syndication.twitter.com might have caused it. Will be difficult for me to guess what trigger this request. However, if you try to recall what actions performed before the crash, shall be quick to reproduce.

- first of all; "options: 172.24.5.25 -l 4 -c 1000" I've changed cache earlier to push limits
- http://fivethirtyeight.com/ was in one of the tabs and I visited 6 Turkish news web site at the same time and also started full speed torrent.

other web sites;

http://www.diken.com.tr/
https://www.ntv.com.tr/
https://www.cnnturk.com/
http://www.hurriyet.com.tr/
http://www.haberturk.com/
http://www.milliyet.com.tr/

tried to reproduce but this time all fine I'll try it again later.

 

[quant88]

18 hrs later. AC88 MEM%=5.2

65915 uts, 2 log, 38 kcc, 87 kmx, 1.39 kvg, 171 krq, 162050 req, 1518 avg, 58430 rmx, 36 tav, 8237 tmx, 22878 slh, 120 slm, 0 sle, 1581 slc, 135586 slu, 184 sct, 155177 sch, 65 scm, 0 scp, 5 sst, 18278 ssh, 1036 ssm, 0 ssp, 2631 nfe, 10 gif, 19 ico, 827 txt, 14 jpg, 1 png, 0 swf, 26 sta, 0 stt, 779 ufe, 0 opt, 19783 pst, 1 hed, 206 rdr, 0 nou, 0 pth, 0 204, 22 bad, 392 tmo, 1633 cls, 0 cly, 0 clt, 0 err

 

[kvic]

tried to reproduce but this time all fine

I tried to playback the sites you visited but hasn't crashed (yet)...

18 hrs later. AC88 MEM%=5.2

Mine still at 3.6% after 24 hours. I see a pattern shaping up...appear to be around 5% of total memory.

 

[elorimer]

rc3 feels slower than rc2. No real change in browsing habits, but my tav is in the 40-60 range; before it had been in the 10-30 range.

 

[kvic]

rc3 feels slower than rc2. No real change in browsing habits, but my tav is in the 40-60 range; before it had been in the 10-30 range.

For a typical home use case, rc.3 shall be faster than rc.2 The optimisation done bends a bit more towards SOHO rather than massive deployment with hundreds of concurrent connections.

Can you try and benchmark your typical websites with Developer Tools in Chrome between the two versions?

 

[vesalius]

On a 3100 uptime - 24 hrs, htop mem% - 2.6%

pixelserv-tls 2.1.0-rc.3 (compiled: Mar 30 2018 17:10:59) options: 10.0.1.3 -l 2
86824 uts, 2 log, 2 kcc, 29 kmx, 3.58 kvg, 404 krq, 9311 req, 1989 avg, 339882 rmx, 4 tav, 798 tmx, 6286 slh, 0 slm, 0 sle, 447 slc, 2407 slu, 100 sct, 3243 sch, 71 scm, 46 scp, 7 sst, 1161 ssh, 153 ssm, 0 ssp, 1684 nfe, 39 gif, 0 ico, 519 txt, 0 jpg, 3 png, 0 swf, 8 sta, 4 stt, 256 ufe, 42 opt, 3450 pst, 0 hed, 405 rdr, 0 nou, 0 pth, 0 204, 0 bad, 43 tmo, 452 cls, 0 cly, 0 clt, 0 err

 

[kvic]

On a 3100 uptime - 24 hrs, htop mem% - 2.6%

pixelserv-tls 2.1.0-rc.3 (compiled: Mar 30 2018 17:10:59) options: 10.0.1.3 -l 2
86824 uts, 2 log, 2 kcc, 29 kmx, 3.58 kvg, 404 krq, 9311 req, 1989 avg, 339882 rmx, 4 tav, 798 tmx, 6286 slh, 0 slm, 0 sle, 447 slc, 2407 slu, 100 sct, 3243 sch, 71 scm, 46 scp, 7 sst, 1161 ssh, 153 ssm, 0 ssp, 1684 nfe, 39 gif, 0 ico, 519 txt, 0 jpg, 3 png, 0 swf, 8 sta, 4 stt, 256 ufe, 42 opt, 3450 pst, 0 hed, 405 rdr, 0 nou, 0 pth, 0 204, 0 bad, 43 tmo, 452 cls, 0 cly, 0 clt, 0 err

Thanks for posting. I see your slu is a non-trivial number. It could be perfectly fine. But if you haven't followed the previous discussion, you may want to go through discussion on rc.1/rc.2 regarding slu.

In a nutshut, it could be caused by clients without CA installed (legitimate), android clients not honouring user CA cert (nothing we can do about but shall be small in request qunatity).

Recently we found that some apps (unknown to users) secretly connect to coin miners. It gets exposed by pixelserv-tls and ends up in slu. These unknown apps refuse handshake if they get presented with a cert not matched with their stored fingerprint (I suspect).

Because of the usefulness of the "debug trace" (i.e. those reason (1048) etc etc) I decided to preserve it as a feature on log LEVEL 2 in release.

Just want to highlight this success story of pixelserv-tls in fulfilling one of its goals - inspect & expose privacy breach.

 

[Asad Ali]

@kvic Hey can you please move the missing certificate generation log entry to level 1 or 0 from level 2 please.

 

[pattiri]

I tried to playback the sites you visited but hasn't crashed (yet)...

I've pushed more and more;

but still no crash

 

[kvic]

@kvic Hey can you please move the missing certificate generation log entry to level 1 or 0 from level 2 please.

It used to be always logged. Some users expressed their will not to see it by default in this thread. Hence, was moved to LEVEL 2 in v2.0.

May you elaborate the thinking behind moving back to 1 or even 0?

 

[Asad Ali]

It used to be always logged. Some users expressed their will not to see it by default in this thread. Hence, was moved to LEVEL 2 in v2.0.

May you elaborate the thinking behind moving back to 1 or even 0?

I don't want to see those multiple 1048 etc reason lines in the log and as you're going to make it permanent in log level two that's why I asked.

 

[kvic]

I don't want to see those multiple 1048 etc reason lines in the log and as you're going to make it permanent in log level two that's why I asked.

If that's the only reason, I could move the "debug trace" to... LEVEL debug. 'cos I already have a better idea to help users catching 'rogue' domains by outputting more informational data at LEVEL 2.

 

[Asad Ali]

If that's the only reason, I could move the "debug trace" to... LEVEL debug. 'cos I already have a better idea to help users catching 'rogue' domains by outputting more informational data at LEVEL 2.

Yup that's the only reason for me and debug trace should be in debug log level anyways, matches the name lol

 

[Butterfly Bones]

If that's the only reason, I could move the "debug trace" to... LEVEL debug. 'cos I already have a better idea to help users catching 'rogue' domains by outputting more informational data at LEVEL 2.

This I like, thank you. I found something interesting, trying to track down where my Pixel 2 XL phone is constantly trying to contact and getting "ssl errors" 1046 as discussed above. So using tcpdump I got a few hundred lines of results.

For example, trying to track this down,

IP Pixel2XL.48983 > lax17s03-in-f14.1e100.net.https:

and this one.

IP Pixel2XL.48983 > den03s10-in-f37.1e100.net.https:

I searched Google for it and it sent me to a site named https://dnslytics.com/ that I had never seen before, but it helps to understand those are both Google sites. At least I know it is not rogue sites.
https://dnslytics.com/ip/216.58.217.37

I am also using this list in AB-Solution as a custom filter list.
https://raw.githubusercontent.com/hoshsadiq/adblock-nocoin-list/master/hosts.txt

I look forward to you plans to provide more info in the pixelserv-tls logging.

 

[kvic]

I already have a better idea to help users catching 'rogue' domains by outputting more informational data at LEVEL 2.

I look forward to you plans to provide more info in the pixelserv-tls logging.

I was about to post an update...here you're:

LEVEL 2 will look like this:

pixelserv-tls[1377]: handshake failed: unknown CA. client 192.168.1.106:36482 server coin.miner.zz
pixelserv-tls[1377]: handshake failed: unknown cert. client 192.168.1.106:36483 server coin.miner.zz

servstats page will be like this:

Feedback welcome as always.

 

[SMS786]

Recently we found that some apps (unknown to users) secretly connect to coin miners. It gets exposed by pixelserv-tls and ends up in slu. These unknown apps refuse handshake if they get presented with a cert not matched with their stored fingerprint (I suspect).

Yessir, just found out that my "ES File Explorer" android app connects to cnhv.co (coinhive network)..even though I bought the paid "ad-free" version. Recommend anyone who has it to uninstall ASAP.

Edit: Just found the AirDroid app also pinging cnhv.co

 

[JaimeZX]

Do you care about v2.0.1 data?
FWIW; 22h 51m uptime: htop says 0.5% of memory, total in use is 205M/503M.

 

[kvic]

Do you care about v2.0.1 data?
FWIW; 22h 51m uptime: htop says 0.5% of memory, total in use is 205M/503M.

Good to hear you eventually sort out everything and get it working. If you want to try the beta rc.3, you can simply run the one-liner in the announcement post a few pages back.

 

[Protik]

After 2d 13;09,

pixelserv-tls 2.1.0-rc.3 (compiled: Mar 29 2018 19:28:58) options: 192.168.2.2 -c 150 -l 2

uts    2d 13:09    process uptime
log    2    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    5    number of active service threads
kmx    46    maximum number of service threads
kvg    4.55    average number of requests per service thread
krq    22806    max number of requests by one service thread
req    30209    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1003 bytes    average size of requests
rmx    61778 bytes    largest size of request(s)
tav    30 ms    average processing time (per request)
tmx    7331 ms    longest processing time (per request)
slh    1605    # of accepted HTTPS requests
slm    16    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    993    # of dropped HTTPS requests (client disconnect without sending any request)
slu    2976    # of dropped HTTPS requests (other TLS handshake errors)
sct    142    cert cache: # of certs in cache
sch    4594    cert cache: # of reuses of cached certs
scm    30    cert cache: # of misses to find a cert in cache
scp    0    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    176    sess cache: # of reuses of cached TLS sessions
ssm    479    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

RAM usage: 2.0% of 250MB.

 

[jrmwvu04]

rc3 rebuild, 9.5MB

uts    1d 12:10    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    30    maximum number of service threads
kvg    2.36    average number of requests per service thread
krq    117    max number of requests by one service thread

req    2917    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1004 bytes    average size of requests
rmx    15520 bytes    largest size of request(s)
tav    7 ms    average processing time (per request)
tmx    1981 ms    longest processing time (per request)

slh    1411    # of accepted HTTPS requests
slm    92    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    133    # of dropped HTTPS requests (client disconnect without sending any request)
slu    634    # of dropped HTTPS requests (other TLS handshake errors)

sct    100    cert cache: # of certs in cache
sch    1211    cert cache: # of reuses of cached certs
scm    25    cert cache: # of misses to find a cert in cache
scp    0    cert cache: # of purges to give room for a new cert
sst    5    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    167    sess cache: # of reuses of cached TLS sessions
ssm    92    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