pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[SMS786]

Thanks for the info. I'm using 2.0.1 from ab-solution add-on so I'll wait for 2.1 then.

https://192.168.1.2/ca.crt works great on rc2..download it and give it a try

 

[jrmwvu04]

RAM usage
1d9h: n1 8.2MB n2 6.5MB
2d16h: n1 13.9MB n2 11MB
3d15h: n1 15.2MB n2 13MB
4d13h: n1 17.9MB n2 17MB

Seeing the RAM usage pattern gets me thinking how some of it is managed inside OpenSSL library...

In my environment, it’s now at 5d11h and 18.8MB. The most I’ve seen so far but also the longest uptime. And to be honest, it’s hard to get worked up with a system ram usage of 57.1MB / 250MB. Though I do understand that nerds of a certain age will remember well that your abilities as a computer user were measured by your system uptime. Some habits die hard.

 

[kvic]

In my environment, it’s now at 5d11h and 18.8MB. The most I’ve seen so far but also the longest uptime. And to be honest, it’s hard to get worked up with a system ram usage of 57.1MB / 250MB.

My n1 at 5d13h 17.8MB RAM. Drops a bit or seems having reached an equilibrium.

n2 is idle (its role taken up by n3). n3 so far looks good at 12h. I'll report back when the new strategy works.

Though I do understand that nerds of a certain age will remember well that your abilities as a computer user were measured by your system uptime. Some habits die hard.

Practically power cycles reduce HW lifespan. So I don't recommend people doing daily or even weekly reboots.

Uptime also demonstrates system robustness. It's a kind of assurance of excellent quality in software..

 

[jrmwvu04]

Well, rc2 is excellent software then.

 

[Makaveli]

My n1 at 5d13h 17.8MB RAM. Drops a bit or seems having reached an equilibrium.

n2 is idle (its role taken up by n3). n3 so far looks good at 12h. I'll report back when the new strategy works.



Practically power cycles reduce HW lifespan. So I don't recommend people doing daily or even weekly reboots.

Uptime also demonstrates system robustness. It's a kind of assurance of excellent quality in software..

Back in the day it would also differentiate the novices users from advanced.

Had a friend who would be reinstalling windows on a weekly basis and lets just say I never let him touch any of my PC's.

 

[kvic]

Had a friend who would be reinstalling windows on a weekly basis and lets just say I never let him touch any of my PC's.

The development of PC (more so on Windows actually..) used to be often compared to car industry. If Windows were cars, it would have crashed and killed many people..

Ironically the "PC" and car industries really cross over with self-driving cars, people just witnessed the first fatal crash sadly.

 

[kvic]

I'll report back when the new strategy works.

I had a deep dive into glibc/pthread in the past few days. It's a rewarding experience. I tried a few ideas. Some works better than others. Also see some discrepancies between different platforms. While Entware is great, I'm not so sure it's tuned for smaller systems. But eventually I came up with something more generic.

Quick tests show it helps containing "blooming RAM usage" in a shorter time and smaller amount. On the longer run I don't have time to see it yet. Hopefully a new rc.3 could be put up for more people to test in the coming few days.

Don't get it wrong. rc.2 is perfectly fine. But in pixelserv-tls, you should expect to get something better as always.

 

[jiznug]

Thank you for development of such a great tool! But how do I install rc2 into ER-X?
Thank you.

 

[kvic]

Thank you for development of such a great tool! But how do I install rc2 into ER-X?

I thought only me. Nice to see another ER-X user running pixelserv-tls. Unfortunately I didn't keep a copy.

I'll upload rc.3 together with other binaries when it's ready.

 

[jiznug]

I thought only me. Nice to see another ER-X user running pixelserv-tls. Unfortunately I didn't keep a copy.

I'll upload rc.3 together with other binaries when it's ready.

Ok. Thanks!

 

[jrmwvu04]

A week in, 19.5MB

 

[kvic]

A week in, 19.5MB

7 day 7 hours 7 minutes....

The rest also looks nice as always.

 

[SMS786]

Just wanted to share my stats after about 3 days. My req count has skyrocketed, for some reason, which in turn has caused my slu to shoot up also. I understand android devices have issues with properly using the ca.cert's loaded into them, but has anyone else seen such high connections in just 3 days? We have a pretty average network setup here (3 laptops, 3 android phones, couple of smart devices, and a chromecast). All of the laptops and phones have the pixelserv cert loaded onto them. One thing I have noticed also is that my skynet stats have shot up too recently, due to 8.8.8.8 being blocked and my chromecast constantly trying to ping it. It's still perfectly functional though, I'm sure it just defaults to the dns servers set up through dnscrypt, perhaps these issues are connected?

Edit: Just fyi running a 68U on 384.4_2.

 

[kvic]

Just wanted to share my stats after about 3 days. My req count has skyrocketed, for some reason, which in turn has caused my slu to shoot up also.

Do you have daily update setup for blocking lists? My guess on the surge would be due to one or more new 'rogue' domains.

It's easy to figure out which domains by turning on log LEVEL 4 temporarily. By the amount of slu you've accumulated in a day or two, if you observe for a mere 5-10mins with the log on, you shall get them.

The below guide not directly related but nevertheless illustrates the principle and how to switch logs without restarting pixelserv-tls.

https://github.com/kvic-z/pixelserv...ut-domain(s)-to-whitelist-on-a-broken-website

 

[Adamm]

my skynet stats have shot up too recently, due to 8.8.8.8 being blocked

FWIW; After the entry appeared in the crypto mining list (god knows why) I put it on the global whitelist as for whatever reason google products tend to probe it constantly.

 

[SMS786]

Do you have daily update setup for blocking lists? My guess on the surge would be due to one or more new 'rogue' domains.

It's easy to figure out which domains by turning on log LEVEL 4 temporarily. By the amount of slu you've accumulated in a day or two, if you observe for a mere 5-10mins with the log on, you shall get them.

The below guide not directly related but nevertheless illustrates the principle and how to switch logs without restarting pixelserv-tls.

https://github.com/kvic-z/pixelserv...ut-domain(s)-to-whitelist-on-a-broken-website

Thanks @kvic. Just turned the log value to level 4. Can you advise as to what I'm specifically supposed to look for now?

FWIW; After the entry appeared in the crypto mining list (god knows why) I put it on the global whitelist as for whatever reason google products tend to probe it constantly.

Yeah seems like google products like to use the mothership's dns servers for whatever reason. I'll prolly blacklist it anyways, just so they resort to my preferred dns.

 

[kvic]

Thanks @kvic. Just turned the log value to level 4. Can you advise as to what I'm specifically supposed to look for now?

In /tmp/syslog.log or through WebGUI, you shall see sample entries like below:

Mar 12 00:59:20 Phaeo pixelserv-tls[6113]: 192.168.1.104 rta.dailymail.co.uk GET /s/l?channel=%2Fnews&_cb=7585259&t=cview&r=http%3A%2F%2Fwww.dailymail.co.uk%2Fhome%2Findex.html&clientSegment=c&g=GB&orientation=portrait&zoom=1&rp=desktop HTTP/1.1
Mar 12 00:59:20 Phaeo pixelserv-tls[6113]: 192.168.1.104 google-analytics.com GET /ga.js HTTP/1.1 secure
Mar 12 00:59:20 Phaeo pixelserv-tls[6113]: 192.168.1.104 tags.crwdcntrl.net GET /c/991/cc.js?ns=_cc991 HTTP/1.1

The first IP (192.168.1.104) is your client. The domain (rta.dailymail.co.uk) is what you've blocked. The URI is what would reach out to real server if not blocked (usually indicative of what the ad server wants to retrieve). A 'secure' keywords indicate that entry is over HTTPS connection.

You shall look for one or more 'rogue' domains that its appearance coincide with surge in slu. Most likely the aliens with most occurrences that aren't usually seen.

The 'rogue' domains could be due to your browsing activities or maybe not. Perhaps first try without doing any human browsing. To catch activities from your appliances. If it's proven quiet i.e. not due to your appliances. Then do some of your daily browsing. Observe the same in both cases i.e. slu and the log.

 

[SMS786]

I ran the level 4 log for about half an hour and seem to be getting variations of the following error:

Mar 28 01:37:20 pixelserv-tls[15450]: getnameinfo failed to get client_ip
Mar 28 01:37:20 pixelserv-tls[15450]: client  ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:09 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:16 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:35 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:43 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:48 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:54 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:55 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:56 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:38:57 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:39:02 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:39:04 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:39:24 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)
Mar 28 01:39:29 pixelserv-tls[15450]: client 192.168.1.169 ssl error:14094416:lib(20):func(148):reason(1046)

The only variations in the error being the client IP addresses being different (due to multiple devices on my network populating the same error). Is this issue perhaps due to android devices not playing nice with the pixelserv cert?

Edit: While our network's browsing is admittedly lighter at this hour of night, I'll keep level 4 logging enabled until tomorrow and see if any more domain-centric errors pop up during normal hours and report back with an update. Thanks again @kvic.

 

[Raphie]

nearly 3 days....

pixelserv-tls 2.1.0-rc.2 (compiled: Mar 20 2018 21:11:49) options: 192.168.1.2
251135 uts, 1 log, 17 kcc, 33 kmx, 1.57 kvg, 2253 krq, 16450 req, 1206 avg, 37901 rmx, 134 tav, 9836 tmx, 11929 slh, 45 slm, 0 sle, 1638 slc, 2483 slu, 100 sct, 9210 sch, 80 scm, 55 scp, 8 sst, 3103 ssh, 40 ssm, 0 ssp, 5483 nfe, 43 gif, 2 ico, 1690 txt, 35 jpg, 20 png, 0 swf, 5 sta, 3 stt, 299 ufe, 36 opt, 1798 pst, 163 hed, 654 rdr, 0 nou, 0 pth, 0 204, 103 bad, 65 tmo, 1638 cls, 1886 cly, 0 clt, 0 err

 

[kvic]

nearly 3 days....

The numbers look very nice.

I knew your router would be only using half of your RAM system wide. For pixelserv-tls process itself, how much RAM does it consume at the moment?

You can look it up in htop (column MEM% row pixelserv-tls). To install "opkg install htop"