pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[kvic]

In the coming days, if no huge issue is found, then the next test version will be rc1. In next version, the benchmark (option '-B') will include both read/write test. It has the benefits to:

• estimate two time sensitive operations in pixelserv-tls on your hardware
• test performance of your thumb drive and CPU
• decide if you need a faster thumb drive for pixelserv-tls (and Entware if you're beyond a basic setup)
• conduct burn-in tests for your brand new thumb drive and router hardware. Run as many instances of 'while(true); do pixelserv-tls -B; done' as CPU cores. Your hardware is happily going to fry...(and some thumb drives decide to slow itself down after the initial 20s)

A quick demo of option '-B' in next version on RT-AC56U @1.2GHz.

 

[Protik]

In the coming days, if no huge issue is found, then the next test version will be rc1. In next version, the benchmark (option '-B') will include both read/write test. It has the benefits to:

• estimate two time sensitive operations in pixelserv-tls on your hardware
• test performance of your thumb drive and CPU
• decide if you need a faster thumb drive for pixelserv-tls (and Entware if you're beyond a basic setup)
• conduct burn-in tests for your brand new thumb drive and router hardware. Run as many instances of 'while(true); do pixelserv-tls -B; done' as CPU cores. Your hardware is happily going to fry...(and some thumb drives decide to slow itself down after the initial 20s)

A quick demo of option '-B' in next version on RT-AC56U @1.2GHz.

In test5, -B without a domain does not work. It seems in rc1 a default domain is picked. Nice!

Sent from my Moto G (5) Plus using Tapatalk

 

[kvic]

In test5, -B without a domain does not work. It seems in rc1 a default domain is picked. Nice!

Sent from my Moto G (5) Plus using Tapatalk

Spot on! The utility of '-B' comes free and yet much more functional because it adds only tiny bit of code to provide the features. The heavy lifting is already inside pixelserv-tls subroutines that are re-used in this case rather than 're-inventing' the wheel.

pixelserv-tls remains tiny and neat. Instant On! Butter Smooth (tm). LOL

 

[Makaveli]

Test 5 22 hours in

I haven't turned off Ad block yet in the browser so cls numbers are still high. I will reset pixelserv and do that tomorrow.

@kvic

Why are my slh # still 0?

 

[Raphie]

RC1 bring it on.

 

[jrmwvu04]

In the coming days, if no huge issue is found, then the next test version will be rc1. In next version, the benchmark (option '-B') will include both read/write test. It has the benefits to:

• estimate two time sensitive operations in pixelserv-tls on your hardware
• test performance of your thumb drive and CPU
• decide if you need a faster thumb drive for pixelserv-tls (and Entware if you're beyond a basic setup)
• conduct burn-in tests for your brand new thumb drive and router hardware. Run as many instances of 'while(true); do pixelserv-tls -B; done' as CPU cores. Your hardware is happily going to fry...(and some thumb drives decide to slow itself down after the initial 20s)

A quick demo of option '-B' in next version on RT-AC56U @1.2GHz.

Our benchmarking screenshots will blot out the sun.

 

[jrmwvu04]

Why are my slh # still 0?

Check and see if you have any pixelserv generated certificates - my guess is not.

ls /opt/var/cache/pixelserv

 

[Butterfly Bones]

Test 5 22 hours in

I haven't turned off Ad block yet in the browser so cls numbers are still high. I will reset pixelserv and do that tomorrow.

@kvic

Why are my slh # still 0?

Mine was like that until I turned off AdGuard AdBlocker that use on sites that pass ads that AB-Solution does not block. Now it increments.

 

[jrmwvu04]

Seems to be ok.

I've disabled the ad block plug in now so just waiting.

You should see it immediately. Open up msn.com or anything really in a browser and your slh counter should rise when you reload the stats page.

 

[Protik]

I set my cache size to 150. After 1d 01:07 and a lot of effort, the sct is 147. Up to now pixelserv is using 16.5MB of memory. That would mean for each cert, pixelserv needs roughly 115KB memory.

For me, the default 100 cache was filling up within 12 hours. Now I want to see what happens to scp after 1 more day.

 

[Makaveli]

You should see it immediately. Open up msn.com or anything really in a browser and your slh counter should rise when you reload the stats page.

I got it working now.

I went into AB-Solution and used the option to purge the Certs.

Then with a restart of Pixelserv the slh counter is going up now.

 

[Jack Yaz]

I got it working now.

I went into AB-Solution and used the option to purge the Certs.

Then with a restart of Pixelserv the slh counter is going up now.

I'd like to make you aware that running asuswrt on your r7000 is not only unsupported here but illegal.

 

[heysoundude]

I'd like to make you aware that running asuswrt on your r7000 is not only unsupported here but illegal.

That sticky at the top of the forum is rather easy to overlook. It's both good and bad to be pointing out transgressions publicly. Perhaps we could be somewhat more discreet in doing so moving forward? Or, as an alternative, explain the possible outcomes and consequences to the project and ecosystem publicly? Then again, and it's been so long that I don't (can't!) remember if I agreed to abide by any terms and conditions of participating here, if a user is deliberately contravening something, I'm sure there are courses of action to be pursued by admins.

@Makaveli I can see your side too - hackers gonna hack. To the best of my knowledge and understanding however, they don't often "neener neener" publicly. A bit more down-low is what's called for on your part too. I'm sure you don't want an exploding inbox from ruining a good thing for a lot of people if the powers that be cotton on and turn up the heat on -and/or yank the rug out from under- those who are driving the bus, right? A proper start would be changing your sig here, and then move on to deleting that post if possible, and then a private apology to @RMerlin, with a gentlemen's agreement to not poke this bear again seems reasonable to me.

 

[jrmwvu04]

I got it working now.

I went into AB-Solution and used the option to purge the Certs.

Then with a restart of Pixelserv the slh counter is going up now.

It always ends up being an overlooked step doesn’t it? I purge the certs directory every time I change versions as a matter of habit. I might have got there, might not have. Either way glad you’re sorted.

 

[MoonPie2000]

Makaveli - I also own a R7000 along with my RT-AC3200 and while I like the Asus-Merlin firmware for many reasons I also like the Tomato firmware found at https://exotic.se/tomato-arm/v2018/2018.1.031/. The Tomato firmware has a very easy ad-blocking software built in. I would suggest that if you haven't looked at this fork of the Tomato firmware you try it. It is actively being developed and has great support at https://www.linksysinfo.org/index.php?threads/fork-tomato-arm-by-kille72.73397/ or https://openlinksys.info/forum/viewthread.php?thread_id=20829&rowstart=0.

 

[kvic]

RC1 bring it on.

I got it working now.

I went into AB-Solution and used the option to purge the Certs.

Then with a restart of Pixelserv the slh counter is going up now.

It always ends up being an overlooked step doesn’t it? I purge the certs directory every time I change versions as a matter of habit. I might have got there, might not have. Either way glad you’re sorted.

In retrospect, since Makaveli uses AB-Solution to manage blocking files in DNSMASQ as well as configuring pixelserv-tls, the problem appears to me then rooting back to the permission of directory (/opt/var/cache/pixelserv) not properly set in earlier ABS.

 

[kvic]

I set my cache size to 150. After 1d 01:07 and a lot of effort, the sct is 147. Up to now pixelserv is using 16.5MB of memory. That would mean for each cert, pixelserv needs roughly 115KB memory.

For me, the default 100 cache was filling up within 12 hours. Now I want to see what happens to scp after 1 more day.

Interesting experiment!

115KB per cert is certainly an over-estimate. Half of that amount perhaps is fair. During KL cycle, I found pixelserv-tls used about 50KB per SSL connection. That's about the RAM usage when a session is to be cached in RAM for speedy resume later.

To have a better ballpark estimate, take the number (sct) you set for SSL cache size. Then estimate average number (say, avg_conn) of connections per cert.

• RAM usage = sct x avg_conn x 50KB

This will still be an overestimate but closer. Two sources of overestimate: 1) 50KB per session 2) avg_conn is hard to guess in version Km

Note that another factor avg_conn is hard to guess is that SSL sessions' valid lifetime is set for 2hrs in version Km. When a session expired after 2hr, a browser will not be able to do a fast resume. I made the call that 2hr is fair assumption because

1. people's average browsing sessions perhaps last that long (or shorter) and then they shutdown browsers completely.
2. extra, say 20ms, every two hour is fair (rather than caching sessions for longer using more RAM that aren't going to be re-used).

Apparently people could see there are a couple of variables that SSL caching could be fined tuned on an ongoing basis in future updates of pixelserv-tls. Just to provide more food for thought for interested users. Hopefully hadn't confused others.

 

[jrmwvu04]

In retrospect, since Makaveli uses AB-Solution to manage blocking files in DNSMASQ as well as configuring pixelserv-tls, the problem appears to me then rooting back to the permission of directory (/opt/var/cache/pixelserv) not properly set in earlier ABS.

It’s difficult at times to know for sure but I suspect there can be issues if newer versions of pixelserv are attempting to reuse certs generated by older versions. Perhaps that’s all in my head - I came up at a time when format c: was the best course of action for software changes. So at this point it is merely a habit I have. That said, I would recommend to anyone to purge your pixelserv certs directory (save for ca.*) when you change versions. No sense in taking a bath in dirty water.

 

[kvic]

It’s difficult at times to know for sure but I suspect there can be issues if newer versions of pixelserv are attempting to reuse certs generated by older versions. Perhaps that’s all in my head - I came up at a time when format c: was the best course of action for software changes. So at this point it is merely a habit I have. That said, I would recommend to anyone to purge your pixelserv certs directory (save for ca.*) when you change versions. No sense in taking a bath in dirty water.

This is a piece of advice with very goodwill, and doesn't hurt either as certs for ad domains purged from disk will be automatically generated by pixelserv-tls on demand again.

However, from an engineering point of view, I shall emphasise that up to now, any certs created by pixelserv-tls since 2.5 yrs ago will work and continue to work...for 10yrs since the date a user creates his root CA certificate.

There might be a change in future versions because older ciphers are gradually phased out by browsers. If that happens, it'll announced ahead of change.

 

[jrmwvu04]

However, from an engineering point of view, I shall emphasise that up to now, any certs created by pixelserv-tls since 2.5 yrs ago will work and continue to work...for 10yrs since the date a user creates his root CA certificate.

I figured that was probably the case.

As I said, it's just a habit formed many years ago to reduce the surface area for problems. There's a reason that 'turn it off and back on' is in the first lessons of tech support 101.

uts    1d 07:45    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.69    average number of requests per service thread
krq    105    max number of requests by one service thread

req    6702    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1706 bytes    average size of requests
rmx    21740 bytes    largest size of request(s)
tav    9 ms    average processing time (per request)
tmx    10003 ms    longest processing time (per request)

slh    2584    # of accepted HTTPS requests
slm    301    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    235    # of dropped HTTPS requests (client disconnect without sending any request)
slu    140    # of dropped HTTPS requests (unknown error)
sct    97    ssl cache: # of cached cert
sch    1482    ssl cache: # of cache hit
scm    97    ssl cache: # of cache miss
scp    0    ssl cache: # of purge to free up slots