pixelserv pixelserv - A Better One-pixel Webserver for Adblock
- Thread starter kvic
- Start date
joe scian
Very Senior Member
Hi Kvic - this is what I get after command
lighttpd 515 joescian 6u IPv4 2088 0t0 TCP *:443
OK thanks - I had ASUS AICloud enabled for Samba on port 443. I originally had it on port 9443 so it defaulted back to port 443 when i installed alpha 2 firmware. Anyway i disabled AICloud completely since I can use OVPN and all good now. Pixelserv now listening on Ports 80 and 443 as per normal. Thanks Kvic - very much appreciated.
I also have my OVPN Server Port set back to 443 and it happily shares it with Pixelserv.
Last edited:
Good to hear..
Seems like OpenVPN and AiCloud (also used to include WebGUI) are common sources..
truglodite
Regular Contributor
Quick question, is open ssl library version 1.0.2o-1 OK to use with pixelserv-tls_beta, or is there a benefit to downgrading to 1.0.2n-1c ? How about the opposite of benefits... is downgrading less secure?
OK to use. At the expense of using up to 6 times more RAM.
The "test" version of 1.0.2n-1c from Entware respository uses 6 times less RAM.
I'm still using 1.0.2n-1c.
Check back previous discussion if you want to read my assessment why it's okay to continue using 1.0.2n-1c security wise.
2.2.0-rc.1 is available
Relatively minor update for router users. Major update for PC/SBC users with the new TLSv1.3 support.
For details, pls see https://kazoo.ga/pixelserv-tls/
Relatively minor update for router users. Major update for PC/SBC users with the new TLSv1.3 support.
For details, pls see https://kazoo.ga/pixelserv-tls/
truglodite
Regular Contributor
I noticed since yesterday an increase in tav, and a noticeable slow down in chrome with 2.1.3test4. I suppose it is from recent updates to chrome. Reading the kazoo.ga site it looks like it may be an issue with tls1.3 not being supported by Entware due to a crusty openssl lib.
I'm guessing upgrading to ps 2.2 won't fix that, correct? Is there a way to gently encourage Entware adoption of openssl 1.1, to maybe get better speed from router pixelserv sooner than later?
I wish I knew enough coding to actually help that along, but for now begging is the most I can offer... or maybe I can figure out how to do rpi with pixelserv tls, but I have no time to do that soon.
I'm guessing upgrading to ps 2.2 won't fix that, correct? Is there a way to gently encourage Entware adoption of openssl 1.1, to maybe get better speed from router pixelserv sooner than later?
I wish I knew enough coding to actually help that along, but for now begging is the most I can offer... or maybe I can figure out how to do rpi with pixelserv tls, but I have no time to do that soon.
As mentioned on my blog, I believe this is a regression in Google Chrome where they're trying to support TLS 1.3 but end up breaking TLS 1.2 a bit. They'll fix it soon in a near future release. Then you'll get your performance back. This is not related to pixelserv-tls nor Entware. If you can't wait, switch to Firefox as a temporary workaround.
Entware is outside my control. My influence perhaps is next to my gravity on Earth. See the libopenssl optimization bit - easy enough to integrate but still outstanding.
Personally I'm against any advocacy/influence/explicit restrictions/implied limitations on my freedom of choices. Hence, my latest recommendation would be inclined to a low-power PC or single-board computer if you want to stay on the forefront of Linux and pixelserv-tls.
Installing pixelserv-tls from source on Rasp Pi is easy and automatic. No requirement to understand the code. Recently, I also filled in the 2nd half of the puzzle. I've seen more people trying. That's a good sign. So a ELI5 guide might not be far away.
Given that said TLS 1.3 is big and the world has anxiously been waiting for years, the rate of adoption shall be pretty fast.
I changed my workflow after 2.1.2. Tentative plan is to push changes to GitHub when a release is done. Small releases will be one lump sum commit. Larger releases will try to break down into logical units of commits.
I'm also pondering if I should migrate the repo to GitLab. Still can't make up my mind. If I decide to do, I would think 2.2 release will make some noise that catch developers attention.
Lastly, I'm exactly expecting someone like you popping up to say hello to me. Looks like a handsome young man, huh? If you're interested in enabling TLS 1.3, a good resource would be OpenSSL's app directory under its tarball. Also OpenSSL promises TLS 1.3 automagically just works. They mostly live up to their promise.
Self-hosting + gogs is another option: https://gogs.io/ As long you don't need a highly social git (with public issue tracker and the likes).
I'm quite comfortable with git the CLI for local repo's. If Gogs can work on existing repo's (can it?), even just for browsing the codes, it'll be hugely useful sometimes. For pixelserv-tls, it needs to stay sociable. At the moment, choices seem limited to GitHub or GitLab.
OpenSSL 1.1.1 is released.
After 9 pre-releases, 1.1.1 was released today...Interestingly they don't call it 2.0 or 1.2 even though the change is non-trivial and the significance of TLS 1.3 is huge and perhaps revolutionary. The main reason is to indicate it's compatible with 1.1.0 at both API and binary levels. 1.1.1 also immediately becomes the new long-term supported version, dethroning 1.0.2 which will stop being supported by the end of 2019. So expect all apps busy testing in the coming year. If all goes well, most ppl shall be on 1.1.1 in a year's time. Here is the announcement.
For pixelserv-tls users, v2.2.0 will be released as soon as after I can get the official version of OpenSSL from Arch Linux to test.
After 9 pre-releases, 1.1.1 was released today...Interestingly they don't call it 2.0 or 1.2 even though the change is non-trivial and the significance of TLS 1.3 is huge and perhaps revolutionary. The main reason is to indicate it's compatible with 1.1.0 at both API and binary levels. 1.1.1 also immediately becomes the new long-term supported version, dethroning 1.0.2 which will stop being supported by the end of 2019. So expect all apps busy testing in the coming year. If all goes well, most ppl shall be on 1.1.1 in a year's time. Here is the announcement.
For pixelserv-tls users, v2.2.0 will be released as soon as after I can get the official version of OpenSSL from Arch Linux to test.
I wouldn't hold my breath with router manufacturers. Some were still on 0.9.8 last time I checked...
Might be worth checking. I know the venerable gitweb does - I have a VPS doing nightly git pulls from Github (for backup purposes, in case something happened to Github), and got gitweb sitting right on top of it.
@kvic and @RMerlin, I have an interesting challenge that I'm hoping one of you may be able to shed light on. With my network setup as follows:
I experience well reported DHCP issues where clients are frequently and intermittently unable to obtain an IP address, seemingly stemming from the issues with the router operating in MB mode. When clients are connected; however, they show up individually in the client list on the router and the pixelserv stats page shows more slh than slu.
After a day of use, the DHCP issues do not occur with the actual MB in the middle and I have had no client connectivity issues. The unique challenge and reason for me soliciting your input is that, in this configuration, clients show on the router network map page as "## clients are connecting to RT-AC86U through this device." I haven't seen any specific limitations yet and custom DHCP assignment appears to still be working along with policy routes defined in the OpenVPN settings. What I have seen impacted with this configuration is pixelserv. Ad blocking with Diversion and pixelserv still appear to work on connected clients, but the servstats doesn't appear to accurately capture that fact:
Code:
AC86U Router <--> AC68P MB <--> AC3200 APWith the continued DHCP issues through 384.5, 384.6, and 384.7 Alpha, I finally had to revert the MB back to my old EA-N66R setup as follows:
Code:
AC86U Router <--> EA-N66R MB <--> AC3200 AP
Code:
pixelserv-tls 2.2.0-rc.1 (compiled: Sep 9 2018 02:47:54 flags: tfo) options: 192.168.50.2 -c 100
uts 0d 23:05 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 2 number of active service threads
kmx 22 maximum number of service threads
kvg 1.16 average number of requests per service thread
krq 39 max number of requests by one service thread
req 471571 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1536 bytes average size of requests
rmx 39906 bytes largest size of request(s)
tav 33 ms average processing time (per request)
tmx 5434 ms longest processing time (per request)
slh 1887 # of accepted HTTPS requests
slm 65 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 1603 # of dropped HTTPS requests (client disconnect without sending any request)
slu 467008 # of dropped HTTPS requests (other TLS handshake errors)
uca 543 slu break-down: # of unknown CA reported by clients
uce 464743 slu break-down: # of unknown cert reported by clients
ush 1339 slu break-down: # of shutdown by clients after ServerHelloI'm having enough challenge from TLS 1.3 at the moment. But thanks for the offer and sharing your problem.
MB=media bridge? I never used media bridge mode in ASUSWRT. Not sure what's under the hood and difference from repeater mode. Regardless, I would think you should capture some frames/packets to see what's going on and open up the problem. pixelserv-tls might show you some phenomenon but it's really not the tool for tackling this sort of problem. Perhaps you should try tcpdump from Entware instead..
truglodite
Regular Contributor
A quick noob question...
My pixelserv generated certs have my pixelserv ip as the CN, and just the blocked website wildcard as the SAN (ie *.googleanalytics.com). I get a green padlock visiting https://pixelservip/servstats. The generated certs also seem to (partially) work based on stats numbers, but not always. When I visit ad rich sites the log shows certs being generated and slh increases. However sometimes I get spikes in uce (client reports unknown cert). Investigating the logs shows this happens to clients with the trusted root cert (win10+chrome, ios+safari, and android+chrome clients).
When I created self signed certs for merlin webui, I had to use the ip as the CN, and put both router.asus.com and the IP in the san. Without the IP in the san, red padlock. Could the unknown cert errors come from the fact that the pixelserv generated certs are missing the IP in the san? If so, could that be added to ps on a future release?
My pixelserv generated certs have my pixelserv ip as the CN, and just the blocked website wildcard as the SAN (ie *.googleanalytics.com). I get a green padlock visiting https://pixelservip/servstats. The generated certs also seem to (partially) work based on stats numbers, but not always. When I visit ad rich sites the log shows certs being generated and slh increases. However sometimes I get spikes in uce (client reports unknown cert). Investigating the logs shows this happens to clients with the trusted root cert (win10+chrome, ios+safari, and android+chrome clients).
When I created self signed certs for merlin webui, I had to use the ip as the CN, and put both router.asus.com and the IP in the san. Without the IP in the san, red padlock. Could the unknown cert errors come from the fact that the pixelserv generated certs are missing the IP in the san? If so, could that be added to ps on a future release?
Last edited:
