AdGuardHome Pixelserv-tls Your AdGuardHome

[SomeWhereOverTheRainBow]

What I am doing so far is not to install ca.crt to any of the devices; it was something that I sort of "dreaded" in having to repeat for all the devices. Some devices, especially smart TV does not support installation of the certificate anyway.

In terms of browsing experience, have not noticed any significant differences. As for performance, this would be hard to quantify as it requires extensive testing and monitoring to a certain extent.

As an alternative, I'm just checking on the "Average processing time" stats in AGH and also "tav" and "tmx" in pixelserv servstats. This would likely be not 100% accurate

the added benefit would come in if AdGuardHome fully supported mapping ipv6 to ipv4

::ffff:192.168.1.4

It will let you input it in the gui for the ipv6 address, but it quickly reverts it to regular 192.168.1.4 instead of holding that value in the GUI. As far as I can tell, the query logs and the AGH server itself will map the AAAA responses to the address AA address. it appears pixelserv-tls maybe able to read the queries from mapped addressing. most of the responses were .02 to .03 ms

 

[unknownz]

the added benefit would come in if AdGuardHome fully supported mapping ipv6 to ipv4

::ffff:192.168.1.4

It will let you input it in the gui for the ipv6 address, but it quickly reverts it to regular 192.168.1.4 instead of holding that value in the GUI. As far as I can tell, the query logs and the AGH server itself will map the AAAA responses to the address AA address. it appears pixelserv-tls maybe able to read the queries from mapped addressing. most of the responses were .02 to .03 ms

By the mapping, do you mean as such? I tried with this and it seems to work fine i.e. blocked AAAA request returns the IPV4 address

 

[chongnt]

IIRC, when ca.crt is re-generated, the existing generated files in cache/pixelserv needs to be removed as well. So that would mean for a redo,
1. stop pixelserv
2. remove all files in cache/pixelserv
3. re-generate ca.crt
4. start pixelserv

Just realized I have backup the cert and over 1000 entries in cache/pixelserv from Diversion. I have successfully restored and installed the certificate. Guess I can keep the cache entries?

 

[SomeWhereOverTheRainBow]

Just realized I have backup the cert and over 1000 entries in cache/pixelserv from Diversion. I have successfully restored and installed the certificate. Guess I can keep the cache entries?

You can try them out but if you start getting ps log errors it may indicate you need to clear them.

 

[Micho]

Greetings! Kind of a stupid question, but I'm not educated in the networking magic and wanted to ask where should I enter those command lines to install pixelserv? Is that in the SSH terminal after I log into the router?

 

[SomeWhereOverTheRainBow]

Greetings! Kind of a stupid question, but I'm not educated in the networking magic and wanted to ask where should I enter those command lines to install pixelserv? Is that in the SSH terminal after I log into the router?

Yes it is done via ssh terminal. And one of the steps involves you using the terminal editor NANO. It should be noted that this is not a required feature that every user "must" have. Adguardhome will function just fine as is. This guide is provided more as an education tool for those who are technically savvy and feel the desire to try something out.

 

[ERamseth2]

FWIW I followed the instructions in the OP here and it worked fine.

However, the Peacock TV service (NBC) does not play nice with pixelserv-tls. It seems to know we're spoofing their ads and it comes up with an error that we "should use a more secure device".

When I switch AGH back to default behavior it works fine.

I guess I could fine tune the rules to return 0.0.0.0 for the Peacock-associated domains and let pixelserv-tls work for the rest of them, but then we're getting way into the weeds.

 

[SomeWhereOverTheRainBow]

FWIW I followed the instructions in the OP here and it worked fine.

However, the Peacock TV service (NBC) does not play nice with pixelserv-tls. It seems to know we're spoofing their ads and it comes up with an error that we "should use a more secure device".

When I switch AGH back to default behavior it works fine.

I guess I could fine tune the rules to return 0.0.0.0 for the Peacock-associated domains and let pixelserv-tls work for the rest of them, but then we're getting way into the weeds.

Either that or make sure the device streaming peacock TV has the appropriate pixelserv tls certificates as a installed cert. (If possible).

 

[ERamseth2]

Either that or make sure the device streaming peacock TV has the appropriate pixelserv tls certificates as a installed cert. (If possible).

Not sure thats possible on androidTV / ShieldTV

 

[SomeWhereOverTheRainBow]

Not sure thats possible on androidTV / ShieldTV

If you are able to access the settings and a web browser from it, you might be able to, similar to how you would on a android smartphone.

 

[Ericardo]

The CPU load of the pixelserv process on my AC86U is hovering around 20-30% (with peaks in the 40s) while AdGuard Home barely moves over 0%. A couple reboots apparently did nothing to calm it down. I don't recall this happening with the pixelserv paired with Diversion. Is this expected? If not, is there anything on the servstats I should pay attention to that may give me a clue about what is causing this load?

 

[SomeWhereOverTheRainBow]

The CPU load of the pixelserv process on my AC86U is hovering around 20-30% (with peaks in the 40s) while AdGuard Home barely moves over 0%. A couple reboots apparently did nothing to calm it down. I don't recall this happening with the pixelserv paired with Diversion. Is this expected? If not, is there anything on the servstats I should pay attention to that may give me a clue about what is causing this load?

The load of running pixelservtls with AdGuardHome may not be adequate for all router models, what router model are you exhibiting this behavior on?

 

[Ericardo]

The load of running pixelservtls with AdGuardHome may not be adequate for all router models, what router model are you exhibiting this behavior on?

It's an AC86U. I've been running Diversion+pixelserv on it without a hitch for over two years, switched to AdGuard Home (without pixelserv) a month ago, also with no problems. Started using the 'standalone' pixelserv three days ago and noticed the high CPU usage. After a reboot or a pixelserv restart its process barely reaches 1% CPU, but a few hours after that, without any radical changes in the home network usage, it goes to the 20-40% zone.

 

[dave14305]

It's an AC86U. I've been running Diversion+pixelserv on it without a hitch for over two years, switched to AdGuard Home (without pixelserv) a month ago, also with no problems. Started using the 'standalone' pixelserv three days ago and noticed the high CPU usage. After a reboot or a pixelserv restart its process barely reaches 1% CPU, but a few hours after that, without any radical changes in the home network usage, it goes to the 20-40% zone.

Look in the Service Threads stats when it is under load. Some clients will repeatedly reattempt a blocked domain, spawning potentially hundreds of Pixelserv threads.

https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/post-562415

 

[SomeWhereOverTheRainBow]

Look in the Service Threads stats when it is under load. Some clients will repeatedly reattempt a blocked domain, spawning potentially hundreds of Pixelserv threads.

https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/post-562415

Interesting.

 

[Ericardo]

Look in the Service Threads stats when it is under load. Some clients will repeatedly reattempt a blocked domain, spawning potentially hundreds of Pixelserv threads.

https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/post-562415

Now that you mention it, I remember seeing around 8 or 10 threads on htop when the load was about 30%. After a restart it goes down to two. AdGuard Home's cache should dampen this spammy behaviour, but I will keep an eye on the threads. Thank you!

 

[ERamseth2]

FWIW with pixelserv-tls just sitting idle (not being directed to) it is using basically zero CPU, so I would say there's nothing that should be happening at idle with CPU usage.

 

[Ericardo]

Look in the Service Threads stats when it is under load. Some clients will repeatedly reattempt a blocked domain, spawning potentially hundreds of Pixelserv threads.

https://www.snbforums.com/threads/diversion-the-router-ad-blocker.48538/post-562415

I may have found the culprit. An old Samsung TV goes bananas when "prov.samsungcloudsolution.com" is resolved to a pixelserv IP. It starts hammering pixelserv with ~20 HTTP requests per second and each pixelserv response makes the TV even angrier. That was enough to spawn 32 threads and send the CPU load to the 20-30% range. The odd part is that at some point I had a maximum of 5 threads (kvg=1, krq=54), and pixelserv's CPU load was already at 25%. There's something wildly inefficient in the way it deals with situations like this.

The solution is to add (in AdGuard) a DNS rewrite to 0.0.0.0 for the domain the misbehaving device so ardently requests. Incidentally, I've found that rewriting some other domains to 0.0.0.0 also fixes a problem I was having with the Amazon app on Android devices (the sad dog picture error). It seems some devices and apps REALLY hate pixelserv.

 

[SomeWhereOverTheRainBow]

I may have found the culprit. An old Samsung TV goes bananas when "prov.samsungcloudsolution.com" is resolved to a pixelserv IP. It starts hammering pixelserv with ~20 HTTP requests per second and each pixelserv response makes the TV even angrier. That was enough to spawn 32 threads and send the CPU load to the 20-30% range. The odd part is that at some point I had a maximum of 5 threads (kvg=1, krq=54), and pixelserv's CPU load was already at 25%. There's something wildly inefficient in the way it deals with situations like this.

The solution is to add (in AdGuard) a DNS rewrite to 0.0.0.0 for the domain the misbehaving device so ardently requests. Incidentally, I've found that rewriting some other domains to 0.0.0.0 also fixes a problem I was having with the Amazon app on Android devices (the sad dog picture error). It seems some devices and apps REALLY hate pixelserv.

Well with cache properly enabled with adguardHome, wouldn't it not constantly hit pixelserv-tls? doesn't this more point to a response caching issue of adguardhome? Or maybe in this instance pixelserv-tls should be trained to turn and respond with 0.0.0.0, doesn't it? What response do you get with dig test and these domains @Ericardo ? do they time out before returning a response? or are they returning pixelserv-tls IP?

 

[Ericardo]

Well with cache properly enabled with adguardHome, wouldn't it not constantly hit pixelserv-tls? doesn't this more point to a response caching issue of adguardhome? Or maybe in this instance pixelserv-tls should be trained to turn and respond with 0.0.0.0, doesn't it? What response do you get with dig test and these domains @Ericardo ? do they time out before returning a response? or are they returning pixelserv-tls IP?

The TV sends a DNS request to AdGuard once per minute, no matter what. Then if the response is a pixelserv IP, it goes crazy 20 times per second with HTTP requests to pixelserv. After one minute it talks to AdGuard again ("Are you SURE this is the IP I'm looking for?"). I don't think responses to blocked domains touch the cache, the AdGuard log simply says the domain is blocked and lists the response (the pixelserv IP), no mention to cached replies (see below). In that case, tweaking the AdGuard cache shouldn't have any effect.

I can't dig test right now, but I don't think it would give us any useful information, since the problem seems to be the TV's inability to accept a pixelserv HTTP response and pixelserv's difficulty in dealing with a deluge of HTTP requests.