What's new

pixelserv pixelserv - A Better One-pixel Webserver for Adblock

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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).
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".
Anything I can do to help troubleshoot this issue? I've added '-l 4' to increase log verbosity and will see what comes up.
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.

You may try to run the latest build from Discord if you can/want. It has improvement in handling 0rtt that possibly has caused a hung process.

Or wait for rc.5 that should be available in a few days time if tests go well.
 
You may try to run the latest build from Discord if you can/want. It has improvement in handling 0rtt that possibly has caused a hung process.

Or wait for rc.5 that should be available in a few days time if tests go well.
I don’t have crush. Can I use that build too?

Just use the wget in the discord? No need the full command that link with “_binfavor=static sh -c” ?
 
I don’t have crush. Can I use that build too?

Just use the wget in the discord? No need the full command that link with “_binfavor=static sh -c” ?

The build on Discord is only for ARMv7 routers, and no fancy script to install the binary. Pretty raw..so people should know what you're doing. You may go ahead or simply wait for rc.5. lol
 
The build on Discord is only for ARMv7 routers, and no fancy script to install the binary. Pretty raw..so people should know what you're doing. You may go ahead or simply wait for rc.5. lol
Lol.. done...
Code:
pixelserv-tls[5911]: pixelserv-tls 2.2.0-rc.4 (compiled: Sep 28 2018 03:10:36 flags: tls1_3) options: 192.168.2.3 -c 400

Need stop diversion first before that -wget.
I just want to be at the edge of technology. Don’t know what I doing. Just have fun. Hahaha..
 
Last edited:
The build on Discord is only for ARMv7 routers, and no fancy script to install the binary. Pretty raw..so people should know what you're doing. You may go ahead or simply wait for rc.5. lol
when is the invitation open again? i'd like to try the non-released build
 
You may try to run the latest build from Discord if you can/want. It has improvement in handling 0rtt that possibly has caused a hung process.

Or wait for rc.5 that should be available in a few days time if tests go well.

Thanks Kvic - am trying latest V3 pixelserv-tls 2.2.0-rc.4 (compiled: Sep 28 2018 06:32:17 flags: tls1_3).

Looks great so far - been giving it a hiding - holding up just fine

I am getting a few of these though
Sep 29 12:08:59 pixelserv-tls[32308]: read_tls_early_data timeout
Sep 29 12:09:08 pixelserv-tls[32308]: read_tls_early_data timeout
Sep 29 12:09:16 pixelserv-tls[32308]: read_tls_early_data timeout
Sep 29 12:09:17 pixelserv-tls[32308]: read_tls_early_data timeout
Sep 29 12:09:30 pixelserv-tls[32308]: read_tls_early_data timeout

pixelserv-tls 2.2.0-rc.4 (compiled: Sep 28 2018 06:32:17 flags: tls1_3) options: 192.168.2.3


uts 0d 01:44 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 24 number of active service threads
kmx 39 maximum number of service threads
kvg 2.61 average number of requests per service thread
krq 169 max number of requests by one service thread
req 3581 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1166 bytes average size of requests
rmx 12304 bytes largest size of request(s)
tav 10 ms average processing time (per request)
tmx 10331 ms longest processing time (per request)
slh 1919 # of accepted HTTPS requests
slm 30 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 827 # of dropped HTTPS requests (client disconnect without sending any request)
slu 72 # 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 64 slu break-down: # of shutdown by clients after ServerHello
sct 50 cert cache: # of certs in cache
sch 951 cert cache: # of reuses of cached certs
scm 48 cert cache: # of misses to find a cert in cache
scp 35 cert cache: # of purges to give room for a new cert
sst 1410 sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh 29 sess cache: # of reuses of cached TLS sessions
ssm 15 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:
when is the invitation open again? i'd like to try the non-released build

Thanks for your interest first of all!

We don’t usually do new binaries there. This is probably the first time because it just happens there is an issue and ppl brought up there.

Also there is no secret nor valuable info there. Rather it’s a more comforting place to exchange ideas e.g. no censorship no freaking buzzwords to prevent u from posting etc. it’s still a public place and everyone should treat it so.

Some people might like to be there. Quite many never speak up and my evil plan is to kick them out perhaps someday. Lol.

I would encourage u to speak up more often here. People will know u a bit more and then fit in a comforting place.

Btw rc.5 should be available in a day or two. Real soon.
 
Recently I was made aware of two efforts that is somewhat related to pixelserv-tls.

1) an OPNsense user finally pops up to create an adblocker for OPNsense.

It’s still at the early stage. The goal is to beat pfBlockerNG. Another user is already proposing to integrate pixelserv-tls. If things play out, then should be good news.

Life for pfSense SOHO users in longer term is a bit cloudy as the company behind will focus on a new platform. OPNsense is something to have eye on.

The relevant thread is here: https://forum.opnsense.org/index.php?topic=9523.0

2) pixelserv-tls receives some attention in pi-hole world. A new gent is requesting a better interoperability with pixelserv-tls. Pi Hole users should watch this request and upvote it if it’s in your interest.

https://discourse.pi-hole.net/t/support-dropping-esni-records-for-blocked-domains/13250
 
Original rc.4 into its 7 days. Tonight hopefully we can release rc.5 with improved compatibility in operations.

Code:
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 6d 16:57 process uptime
log 2 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 116 maximum number of service threads
kvg 2.44 average number of requests per service thread
krq 3286 max number of requests by one service thread
req 69379 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1546 bytes average size of requests
rmx 149723 bytes largest size of request(s)
tav 49 ms average processing time (per request)
tmx 14073 ms longest processing time (per request)
slh 50227 # of accepted HTTPS requests
slm 33 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 5367 # of dropped HTTPS requests (client disconnect without sending any request)
slu 5972 # 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 2097 slu break-down: # of shutdown by clients after ServerHello
 
Recently I was made aware of two efforts that is somewhat related to pixelserv-tls.

1) an OPNsense user finally pops up to create an adblocker for OPNsense.

It’s still at the early stage. The goal is to beat pfBlockerNG. Another user is already proposing to integrate pixelserv-tls. If things play out, then should be good news.

Life for pfSense SOHO users in longer term is a bit cloudy as the company behind will focus on a new platform. OPNsense is something to have eye on.

The relevant thread is here: https://forum.opnsense.org/index.php?topic=9523.0

2) pixelserv-tls receives some attention in pi-hole world. A new gent is requesting a better interoperability with pixelserv-tls. Pi Hole users should watch this request and upvote it if it’s in your interest.

https://discourse.pi-hole.net/t/support-dropping-esni-records-for-blocked-domains/13250
I have appeared on the pi-hole discourse forum a few times trying my best to persuade the pi-hole devs to include pixelserv-tls. They mentioned the MTM concern the first time. Thanks for sharing the update!
 
I have appeared on the pi-hole discourse forum a few times trying my best to persuade the pi-hole devs to include pixelserv-tls. They mentioned the MTM concern the first time. Thanks for sharing the update!

I believe your persistence worked out, particularly the last round. So perhaps you should be proud of the difference you made.

I also had the gut feeling ppl picked up a thing or two from my blog or some of the discussion we did on this forum. Devs surely carry a friendlier tone than before. Misconception in users may need more time to clear out.

Btw if u want a project with profound impact, perhaps you should consider participating in the opnblocker for opnsense.
 
2.2.0-rc.5 is available

We solved a difficult problem. For changes, pls see kazoo.ga/pixelserv-tls/

The debug process and credits

As some of you may know, rc.4 gets into a "hung" state for some people. To work out this issue, we get many helps from a few pixelserv-tls ninjas.

In retrospect, pixelserv-tls never actually hangs. It's like as @elorimer described that the response returned after 26s of waiting. That was corroborated in @M@rco's description in his case that came up later. For unknown reasons, when the issue happens and it's inside OpenSSL, it takes a varying amount of time to get itself out the stuck state but it did get out eventually. While pixelserv-tls gets in such a stuck state, a flood of requests might actually crash the process though very rare. I recall a crash only happened once as per @Protik's description.

We should thank all the mentioned names in their contribution to get a better understanding of the problem. @Protik in particular was the first one reporting the issue and ever since worked enthusiastically in getting to the bottom of this issue. That really kept the momentum going inside the silo.

I should not forget to mention @quant88 who happened to encounter the issue, responded quickly and was able to swiftly take the first backtraces. If I didn't remember wrongly he was also one of first guys a year ago that helped solving the riddle of a hung pixelserv-tls. The first backtraces really opened up the problem to a new level.

Luckily we also have @jrmwvu04 who in the middle of the process jumped to the frontline with a 100% reproducible case that was dearly sought after and was left on the table idle for a little while. From there the understanding of the issue and possible fixes were almost all on the plate, and we were able to proceed swiftly to a conclusion.

Forgot to mention @joe scian who also provided a 100% reproducible case at later stage.

Thank you.
 
2.2.0-rc.5 is available

We solved a difficult problem. For changes, pls see kazoo.ga/pixelserv-tls/

The debug process and credits

As some of you may know, rc.4 gets into a "hung" state for some people. To work out this issue, we get many helps from a few pixelserv-tls ninjas.

In retrospect, pixelserv-tls never actually hangs. It's like as @elorimer described that the response returned after 26s of waiting. That was corroborated in @M@rco's description in his case that came up later. For unknown reasons, when the issue happens and it's inside OpenSSL, it takes a varying amount of time to get itself out the stuck state but it did get out eventually. While pixelserv-tls gets in such a stuck state, a flood of requests might actually crash the process though very rare. I recall a crash only happened once as per @Protik's description.

We should thank all the mentioned names in their contribution to get a better understanding of the problem. @Protik in particular was the first one reporting the issue and ever since worked enthusiastically in getting to the bottom of this issue. That really kept the momentum going inside the silo.

I should not forget to mention @quant88 who happened to encounter the issue, responded quickly and was able to swiftly take the first backtraces. If I didn't remember wrongly he was also one of first guys a year ago that helped solving the riddle of a hung pixelserv-tls. The first backtraces really opened up the problem to a new level.

Luckily we also have @jrmwvu04 who in the middle of the process jumped to the frontline with a 100% reproducible case that was dearly sought after and was left on the table idle for a little while. From there the understanding of the issue and possible fixes were almost all on the plate, and we were able to proceed swiftly to a conclusion.

Forgot to mention @joe scian who also provided a 100% reproducible case at later stage.

Thank you.

Where's my name?? I provided moral support since I'm on 86U [emoji1787][emoji1787][emoji1787][emoji1787][emoji16]
 
Where's my name?? I provided moral support since I'm on 86U [emoji1787][emoji1787][emoji1787][emoji1787][emoji16]

Oh yea..@Asad Ali is the spirit of the silo

We also have @truglodite for guest shot & brief appearance, and later @DonnyJohnny for a brief of intensive tests.

Also we have to thank the janitors of the silo..and the beautiful tea & coffee ladies.

thanks all!
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top