[no longer need feedback] pixelserv-tls users: How's your setup

[thelonelycoder]

Hey all
AB-Solution, the Ad-Blocking solution, will have the option to use an existing install of pixelserv-tls, or if it's not installed, have it do so.

To get the integration right and to make up my mind about a few things, I need some input how you use pixelserv-tls at the moment. You may help me even if you're not using AB-Solution

I am interested in what settings you have in:
- /opt/etc/init.d/S80pixelserv-tls, the ARGS and maybe the PREARGS are of most interest.
- Do you run pixelserv with or without the -tls option, meaning do you only run http
- Do you run the router Web-UI on https or still on http?
- Refering to above, if on http, what hack do you use to run pixelserv-tls?
- Anything you might want to contribute

Thanks in advance for your answers.

Edit: Thanks for your insights, I know where I'm heading now with AB-Solution.

 

[jrmwvu04]

- ARGS and PREARGS both blank
- with tls (I don't know that there's much point without)
- webUI on http, it's slow on https and I don't feel like bothering with the certs/warnings
- webUI on port 8080

I know that's a rather unimpressive setup but I found after much tinkering that letting pixelserv do its thing with the default setup eliminated setup mistakes and issues. Moving the webUI is far less trouble in my opinion. But to each their own.

 

[thelonelycoder]

I found after much tinkering that letting pixelserv do its thing with the default setup eliminated setup mistakes and issues.

I can relate. Thanks for sharing.
Which way do you set the http WebUI port?

 

[jrmwvu04]

I use john's fork, so I'm not sure if it's applicable outside of that, but it's the "http_lanport" nvram variable. I believe it's in the gui as well, but I'm
away from home and cannot check.

 

[thelonelycoder]

I use john's fork, so I'm not sure if it's applicable outside of that, but it's the "http_lanport" nvram variable. I believe it's in the gui as well, but I'm
away from home and cannot check.

Can't find it in Merlin FW, only https is user configurable.
I would think that @john9527 has built that option into the UI.

 

[thelonelycoder]

- with tls (I don't know that there's much point without)

I was thinking of having the option of using pixelserv-tls in the way the original pixelserv was used: Only http requests are handled.
There are a lot of grievances to be had if tls is used without the certs either properly set or missing on the users devices.
I'm not saying it does not work, @kvic and others did a great job. I just noticed there were a lot of questions and problems posted in other threads.

 

[mstombs]

I use pixelserv-tls on an old N66U, have moved webui to https non standard port, as still on 380.59. Use own script to get pgl.yoyo dnsmasq domain blocklist. Not sure still needed but get pixelserv to listen on main and common alternate http ports, 80,81, 8080,8081. -o 2 reduces timeout to an old default, from current 10 seconds, hangover from testing something....

pixelserv-tls version: V35.HZ12.Kh compiled: May 11 2016 15:13:54 options: 192.168.66.254 -p 80 -p 81 -p 8080 -p 8081 -k 443 -o 2
uts: Uptime 68 days 13:14
req: Total # of requests 5723313
avg: Avg size of reqs 1320 bytes
rmx: Max size of reqs 42122 bytes
tav: Avg process time 109 ms
tmx: Max process time 4159 ms
err: # of error reqs 0
tmo: # of client timeout 10782
cls: # of client shutdown 5652636
nou: # of reqs w/o URL 0
pth: # of invalid URL 0
nfe: # of missing file ext 15860
ufe: # of unknown file ext 2741
gif: # of GIF reqs 661
bad: # of unknown HTTP methods 0
txt: # of TXT reqs 22483
jpg: # of JPG reqs 62
png: # of PNG reqs 163
swf: # of SWF reqs 26
ico: # of ICO reqs 21
slh: # of HTTPS /w a good cert 5606614
slm: # of HTTPS w/o a cert 97
sle: # of HTTPS /w a bad cert 0
slu: # of unrecognized HTTPS 3104
sta: # of HTML stats 16
stt: # of text stats 3
204: # of HTTP/204 (no content) 0
rdr: # of redirects 17425
pst: # of POST method 392
hed: # of HEAD method 0
log: access log enabled (0=no 1=yes) 0

Note - most blocked ads requests now are served by https, very few simple images served, still not sure why there are so many 'client shutdown' - I suspect these are from browsers without the certificate installed.

I use https option on a couple of machines I have control over - you need to import certificates into browser to work properly, but I feel it still works fine with other devices that are not so set up - the ssl negotiation seems to fail silently?

 

[thelonelycoder]

http ports, 80,81, 8080,8081. -o 2 reduces timeout to an old default, from current 10 seconds, hangover from testing something....

Haha, yeah.

thessl negotiation seems to fail silently?

Haven't tested that, I'm hoping it falls back to http only if no certs are present.

 

[kvic]

I was thinking of having the option of using pixelserv-tls in the way the original pixelserv was used: Only http requests are handled.

Seems you lost your way a bit. Here I am This approach will not save any effort on both yourself and users.

In my opinion, with ab-solution you achieved a giant leap from setup instructions (of many steps) to a hassle free process to complete in one go with a single script. The amount of time you're willing to dedicate on this effort surprises me and some other members I would think.

With more integration (and moving parts/options), the complexity escalates exponentially. There is so much so one could integrate and remain simple in implementation and user experience.

IMHO, installation of Entware, pixelserv-tls and setup of it and how to run WebUI shall be excluded and remain outside your script. But add an option to allow users to change IP address from 0.0.0.0 to something they could enter. Call it pixelserv friendly option or something.

Let users handle Entware/pixelserv install etc separately if they want the functionality. Small parts work together to achieve a bigger goal. The Unix way I prefer personally.

 

[mstombs]

You cannot auto fall back, if the browser tries to make an https request previous pixelserv https://github.com/HunterZ/pixelserv just tries to refuse connection quickly (no timeouts, few repeats). pixelserv-tls tries to negotiate using a real certificate. It would be up to the web page scripts in the browser to try an http address if https certificate refused.

NB the stats maintained by having pixelserv as an advert divert target are interesting, and the log option of pixelserv-tls should be great help to find out why some sites do not work ...

 

[thelonelycoder]

Seems you lost your way a bit. Here I am This approach will not save any effort on both yourself and users.

In my opinion, with ab-solution you achieved a giant leap from setup instructions (of many steps) to a hassle free process to complete in one go with a single script. The amount of time you're willing to dedicate on this effort surprises me and some other members I would think.

With more integration (and moving parts/options), the complexity escalates exponentially. There is so much so one could integrate and remain simple in implementation and user experience.

IMHO, installation of Entware, pixelserv-tls and setup of it and how to run WebUI shall be excluded and remain outside your script. But add an option to allow users to change IP address from 0.0.0.0 to something they could enter. Call it pixelserv friendly option or something.

Let users handle Entware/pixelserv install etc separately if they want the functionality. Small parts work together to achieve a bigger goal. The Unix way I prefer personally.

I was unconsciously waiting for a response like yours.
I am working on a lot of other improvements, bug-fixes and additions to AB-Solution at the moment. And I realized I deliberately kept away from the pixelserve-tls integration code that's in beta2.
I'm having lunch now and will think about it. Thanks for bringing this up.

 

[kvic]

Note - most blocked ads requests now are served by https, very few simple images served, still not sure why there are so many 'client shutdown' - I suspect these are from browsers without the certificate installed.

Interesting numbers on 'client shutdown'. I didn't recall it was that big in your last post of servstats. I observed the same on @Goobi 's servstats too. This shutdown's shall not have been caused by TLS negotiation as e.g. in your case "HTTPS /w a good cert" is very good!

Will be interesting science to find out what causes it. Perhaps by latest browser update..some of those become aggressive in achieving performance.

 

[kvic]

You cannot auto fall back, if the browser tries to make an https request previous pixelserv https://github.com/HunterZ/pixelserv just tries to refuse connection quickly (no timeouts, few repeats). pixelserv-tls tries to negotiate using a real certificate. It would be up to the web page scripts in the browser to try an http address if https certificate refused.

The plain pixelserv is not available on Entware. More hassle to get it installed automatically. With pixelserv-tls, only require ca.crt & ca.key to be generated. For clients not have imported the CA cert, on HTTPS adserver it'll negotiate once and stop.

That's if I remember correctly..only once and stop. Unlike pixelserv, the client will desperately iterate through all crypto algos supported by the client browser and being rejected each time by pixelserv. So there is benefit from pixelserv-tls even on this aspect. But hey average users won't care such details frankly.

NB the stats maintained by having pixelserv as an advert divert target are interesting, and the log option of pixelserv-tls should be great help to find out why some sites do not work ...

The log function is very helpful I should emphasise. It saved me on multiple malfunction sites due to adblock.

 

[kvic]

I use john's fork, so I'm not sure if it's applicable outside of that, but it's the "http_lanport" nvram variable. I believe it's in the gui as well, but I'm
away from home and cannot check.

You're right. John's fork added this function long time ago. Exclusive feature to his fork. Exclusive in a sense that others aren't interested in porting for reasons with merits or not.

But the situation isn't bad in stock and Merlin after Asus made the change and only bind WebUI to one IP address (one interface, br0 be precise). WebUI shall no longer require consideration with respect to installation of pixelserv or any other web servers on the router.

 

[thelonelycoder]

Thank you all for participating, I've made up my mind.
The next AB-Solution release will seamlessly work with YOUR pixelserve-tls install.
Or any other method you have that requires a (combined) hosts file.