pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[Jack Yaz]

“You’ve broken the Internet. Again! Why can’t we get a router that doesn’t break down, like everyone else has?”

Next try developing scripts in a live environment (not ideal but no funds for a dev router )

"Why do you have to touch things, leave the router alone!"

 

[martinr]

Next try developing scripts in a live environment (not ideal but no funds for a dev router )

"Why do you have to touch things, leave the router alone!"

Well it’s taken me 17 years to get mine close to understanding that maximum heat on the cooker doesn’t raise the boiling pont of water, it only fills the house with condensation. So I can’t imagine how you go about explaining what you did to “break the Internet”.

 

[XIII]

A lot, pixelserv will not start.

It seems to do?

/opt/etc/init.d/S80pixelserv-tls check
 Checking pixelserv-tls...              alive.

This will restore the proper (lovingly curated and coded by the Diversion developer) S80 start file.

Indeed. Thanks!

 

[RMerlin]

OpenSSL 1.1.x library doesn't enable memory optimization.

Which one specifically? The OPENSSL_NO_BUF_FREELISTS option for instance no longer exists in 1.1.1:

merlin@ubuntu-dev:~/amng/release/src/router/openssl-1.1.x$ grep OPENSSL_NO_BUF_FREELISTS * -r
merlin@ubuntu-dev:~/amng/release/src/router/openssl-1.1.x$

 

[cmkelley]

Because I couldn't help myself, I ran opkg update/upgrade.

1. This will overwrite the static build of 2.2.1 (2/27/19) with a dynamic build of 2.2.1 (3/22/19). Rerun amtm to restore.
2. This will overwrite the S80pixelserv so lovingly created by diversion, so before doing it make a backup to restore after.
3. This will overwrite the S01syslog-ng file, which needs to be customized to work, so make a backup to restore after.
4. This will not overwrite the syslog-ng.conf and logrotate.conf file (yay!). The syslog-ng.conf file is updated to version 3.19, and moves the @include statement as requested by @cmkelley . Although I see it moves it to before the source definitions, so I am not sure if it works if you have destinations, filters and logging defined in the subdirectory that uses those sources if they are not yet defined. It also adds TLS support if you have the key/crt files (does that help us?) and scl.conf support (does that help us?) The logrotate file is the same.

EDIT: Yikes. More:

1. Syslog-ng won't start with the TLS source defined as it is in the default log. Comment out the whole TLS source thing. Fails the -s test too.
2. I also upgraded Stubby through AMTM, and that borked my internet connection. I disabled it by deleting the WAN DNS address and going to "connect automatically" for the moment.

Actually, the upstream had moved it before I asked the Entware folks, it wasn't a result of my suggestion.

Also, my current @include line is at the very top and it works without issue. Syslog-ng is smart enough to process all the source directives first.

 

[na_0]

Edit:. Sorry, I had dns66 (a separate ad blocker) running by mistake, that was causing my problems. Any pointers on how I went wrong with tls 1.3 in raspbian would be much appreciated however!


Hi all,
I just installed pixelserv-tls on raspbian stretch (raspberry pi), and it seems to be working for the most part - I can get the servstats page and see http and https requests are being served. I've installed the ca cert on my Android device. But, I still see many https ads (mostly doubleclick.net) in chrome with the 404 error, not the pixel.

Can anyone help me with pointers to troubleshoot? I have the no tls1.3 flag - I think I did something wrong when compiling but would this cause my problem?

Thanks for any help!

 

[cmkelley]

4. This will not overwrite the syslog-ng.conf and logrotate.conf file (yay!). The syslog-ng.conf file is updated to version 3.19, and moves the @include statement as requested by @cmkelley . Although I see it moves it to before the source definitions, so I am not sure if it works if you have destinations, filters and logging defined in the subdirectory that uses those sources if they are not yet defined. It also adds TLS support if you have the key/crt files (does that help us?) and scl.conf support (does that help us?) The logrotate file is the same.

In this case, it might be wise to rename your current syslog-ng.conf file when upgrading so it will install the new one. The syslog-ng.conf file included with 3.19 appears to already have the TLS line commented out. Or are you saying the default .conf file errors out? That would be bad. I haven't installed 3.19 yet, I'm still trying to figure out the correct way to upgrade to the latest Entware drop.

 

[elorimer]

Here is what the default .conf file included for me:

source s_network {
    default-network-drivers(
        # NOTE: TLS support
        #
        # the default-network-drivers() source driver opens the TLS
        # enabled ports as well, however without an actual key/cert
        # pair they will not operate and syslog-ng would display a
        # warning at startup.
        #
        #tls(key-file("/path/to/ssl-private-key") cert-file("/path/to/ssl-cert"))
    );
};

Using this, syslog-ng failed to start for me. Checking it with the -s parameter flagged an error on the default-network-drivers line. So I think the whole block needs to be commented out or it will choke on what is left uncommented.

Thanks, by the way, for answering whether the placement of the @include statement was a problem.

When it comes to updating both logrotate and syslog-ng, it notices that the default .conf files are different than the existing .conf files, and puts up a warning and names the new default files .conf-pkg. Pretty slick.

 

[kvic]

Any pointers on how I went wrong with tls 1.3 in raspbian would be much appreciated however!

If you link against openssl 1.1.1, you'll get tls 1.3 features and see this flag on servstats page. 1.1.x may not be available on Raspian yet. You could try to pull it yourself. Do you happen to have written/seen a config guide and perhaps could share with raspiban users (assume u run pinhole on it)?

As an aside, here is pixelserv-tls thread for OpenWRT.

 

[Xentrk]

If you link against openssl 1.1.1, you'll get tls 1.3 features and see this flag on servstats page. 1.1.x may not be available on Raspian yet. You could try to pull it yourself. Do you happen to have written/seen a config guide and perhaps could share with raspiban users (assume u run pinhole on it)?

As an aside, here is pixelserv-tls thread for OpenWRT.

Thanks for reminder @kvic. I forgot about pixelserv-tls support on OpenWRT. I am using my gl-iNet travel router the next two weeks while living out of a hotel room. I recently updated to the new 18.06.1 firmware and had to reinstall adblock yesterday. I'll jump over the OpenWRT forum and your blog for next steps to install pixelserv-tls.

EDIT: Not ready yet? I see the [To be updated] text in the post. I'll check in periodically. Let me know if I can help with any testing.

 

[na_0]

If you link against openssl 1.1.1, you'll get tls 1.3 features and see this flag on servstats page. 1.1.x may not be available on Raspian yet. You could try to pull it yourself. Do you happen to have written/seen a config guide and perhaps could share with raspiban users (assume u run pinhole on it)?

As an aside, here is pixelserv-tls thread for OpenWRT.

Thanks you are right 1.1.1 is not available on raspbian yet, I was using an older version. I'll build 1.1.1 and recompile thank you.

I'm actually not using pihole, but instead dnsmasq on an edgerouter. I haven't been able to find any config guides but pieced it together from your help and some guides for the old pixelserv. Thanks so much for your effort to maintain pixelserv-tls now that I have it running I think it is far far better than dnsmasq alone.

 

[vesalius]

Per my Pixelserv-tls servstats page, tls 1.3 is working with just released stock iOS 12.2 on both iphone and iPad after the update this afternoon. Not seeing anything moving on the 0-RTT front though so that implementation is likely still lacking, at least on an untweaked default iOS install.

 

[cmkelley]

Moving the syslog-ng conversation over to where it belongs ... https://www.snbforums.com/threads/c...with-merlin-firmware.35095/page-5#post-474717

 

[elorimer]

As @kvic mentioned, the static linked version has the benefit of being compiled with a memory optimization flag which pretty dramatically cuts down on memory use by pixelserv. For the moment I'm going to continue with it while the dust settles.

Following along with what @Merlin wrote, under 384.9 the dynamic build was at 1.4% memory (no TLS 1.3) and the static build with TLS 1.3 was 1.7% memory. Under 384.10, the static build was 1.7% memory, and the dynamic build was also 1.7% memory. So there doesn't appear to be a memory optimization anymore.

 

[na_0]

If you link against openssl 1.1.1, you'll get tls 1.3 features and see this flag on servstats page. 1.1.x may not be available on Raspian yet. You could try to pull it yourself. Do you happen to have written/seen a config guide and perhaps could share with raspiban users (assume u run pinhole on it)?

As an aside, here is pixelserv-tls thread for OpenWRT.

Hi all,
I installed openssh 1.1.1 from raspbian buster so I could use tls 1.3 support for pixelserv-tls. Http works great, but I get SSL errors for https on all devices. My servstats shows thousands of sle errors (certificate available but not usable). I've tried deleting and installing new CAs. Does anyone have any pointers for helping me to troubleshoot this?

 

[DivideBy0]

Hi all,
I installed openssh 1.1.1 from raspbian buster so I could use tls 1.3 support for pixelserv-tls. Http works great, but I get SSL errors for https on all devices. My servstats shows thousands of sle errors (certificate available but not usable). I've tried deleting and installing new CAs. Does anyone have any pointers for helping me to troubleshoot this?

I'm running pixelserv-tls 2.2.1 on rasbian stretch as well.
I've got OpenSSL 1.1.0j running, and installed libssl-dev 1.1.1b from testing (just upgraded from 1.1.1a the other day) to make pixelserv-tls with tls1_3.
All is working well for me.
Did you have certs generated in /var/cache/pixelserv that existed before you upgraded to 1.1.1? If so you may want to stop pixelserv-tls, delete those certs (do not delete ca.crt and ca.key) and then fire it up again. At that point it will generate the needed certs again.
This may get you usable certs.

 

[na_0]

I'm running pixelserv-tls 2.2.1 on rasbian stretch as well.
I've got OpenSSL 1.1.0j running, and installed libssl-dev 1.1.1b from testing (just upgraded from 1.1.1a the other day) to make pixelserv-tls with tls1_3.
All is working well for me.
Did you have certs generated in /var/cache/pixelserv that existed before you upgraded to 1.1.1? If so you may want to stop pixelserv-tls, delete those certs (do not delete ca.crt and ca.key) and then fire it up again. At that point it will generate the needed certs again.
This may get you usable certs.

Thanks so much, helps to know it can work. I might have broken something by updating openssl to 1.1.1 first, and then libssl. I didn't have any certs cached I did a clean install of stretch + buster openssl and libssl. I'll try again.

 

[DivideBy0]

Thanks so much, helps to know it can work. I might have broken something by updating openssl to 1.1.1 first, and then libssl. I didn't have any certs cached I did a clean install of stretch + buster openssl and libssl. I'll try again.

Glad to help!
I had been updating openssl and libssl then backing off the version of openssl as 1.1.1 wasn't playing nice with other installed things as of yet. Just decided for this last update I did to only update libssl and leave openssl at 1.1.0.. worked like a champ and saved me a few steps.

 

[na_0]

Glad to help!
I had been updating openssl and libssl then backing off the version of openssl as 1.1.1 wasn't playing nice with other installed things as of yet. Just decided for this last update I did to only update libssl and leave openssl at 1.1.0.. worked like a champ and saved me a few steps.

Can't thank you enough DivideBy0, your suggestion fixed my issue! I wouldn't have figured this out on my own. Pixelserv-tls is working great for me now including tls 1.3.

 

[DivideBy0]

Can't thank you enough DivideBy0, your suggestion fixed my issue! I wouldn't have figured this out on my own. Pixelserv-tls is working great for me now including tls 1.3.

@na_0 , Glad I was able to lend a hand, very glad it's working!