What's new

pixelserv pixelserv - A Better One-pixel Webserver for Adblock

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Ok so I've successfully installed the openssh-sftp-server. Am I supposed to see it somewhere in the router GUI? I've been looking but haven't found anything so far.

You need to install Filezilla on the mac and then connect to the SFTP server I believe. Then you will be browsing to the file location from inside Filezilla non of this will be done thru router GUI.
 
  • Like
Reactions: #TY
No, just launch your SFTP agent and you will get prompted for security access, nothing more to do, at least on my end (Linux PC to Linux router).
BINGO!!

Thank you VERY much kind sir. I would have NEVER figured out the having to install the sftp package first :)

pixelserv-tls has now been successfully updated to 2.3.1
 
Did you install this on a separate Linux distro or in your router? If the latter, do you mind sharing the installation steps?

Thank you!

Hey @Marin, you run testssl.sh from your local machine and point to your pixelserv-tls IP i.e.
Code:
./testssl.sh 192.168.1.2
- substitute the example with the IP of your pixelserv

Furthermore, you can also run testssh.sh with --client-simulation to see how different clients negotiate the TLS versions as well as which ciphers are using.
Code:
./testssl.sh --client-simulation 192.168.1.2

Output should be as per below screenshot.
upload_2019-12-26_19-33-20.png
 
Also here are the steps for the manual update of pixelserv-tls in case someone needs assistance until it gets updated in the entware repos.

Code:
ssh to your router and find pixelserv-tls
admin@yourrouter:/tmp/home/root# which pixelserv-tls
/opt/bin/pixelserv-tls

close your ssh session

Download the latest pixelserv-tls from github on your local machine: https://github.com/kvic-z/pixelserv-tls/releases/tag/v2.3.1  - choose the version compatible with your router

wget https://github.com/kvic-z/pixelserv-tls/releases/download/v2.3.1/pixelserv-tls.2.3.1.Entware-ng.armv7softfloat.zip

create new dir: mkdir pixelserv

unzip the archive: unzip pixelserv-tls.2.3.1.Entware-ng.armv7softfloat.zip -d pixelserv

cd to pixelserv/dist and rename/move the file

mv pixelserv-tls.arm.ent.performance.dynamic ~/Downloads/pixelserv/pixelserv-tls

upload the file to your router /tmp dir first
scp pixelserv-tls admin@192.168.1.1:/tmp/

ssh to your router and copy the file in the correct directory (remember /opt/bin/pixelserv-tls)
cp /tmp/pixelserv-tls /opt/bin/pixelserv-tls

check the permissions: ls -la /opt/bin/pixelserv-tls
 
Could someone please post pixelserv stats?

I'm interested in:
tav - average processing time (per request)
tmx - longest processing time (per request)

I'm actually surprised that such a tiny package like pixelserv-tls also has support for
zrt - TLS 1.3 Early Data aka 0-RTT - super cool!

upload_2019-12-26_20-54-54.png
 
Hey @Marin, you run testssl.sh from your local machine and point to your pixelserv-tls IP i.e.
Code:
./testssl.sh 192.168.1.2
- substitute the example with the IP of your pixelserv

Furthermore, you can also run testssh.sh with --client-simulation to see how different clients negotiate the TLS versions as well as which ciphers are using.
Code:
./testssl.sh --client-simulation 192.168.1.2

Output should be as per below screenshot.
View attachment 20456

Thank you. These commands don’t produce any output on my end because I am sure I need to install something else and I have not been able to figure it out yet. I went to the website on Github and downloaded the most stable source code (3.06 I think) but did not have enough time to follow all the steps on how to install to a local machine.


Sent from my iPhone using Tapatalk
 
Which version of testssl.sh are you using?

I tried 2.9.5-8 (via brew install) on a MacBook Pro, but the highest Safari simulated is "Safari 10 for OS X 10.12" (and "Safari 7 for iOS 7.1"); rather outdated...
 
No, just launch your SFTP agent and you will get prompted for security access, nothing more to do, at least on my end (Linux PC to Linux router).
You need to install Filezilla on the mac and then connect to the SFTP server I believe. Then you will be browsing to the file location from inside Filezilla non of this will be done thru router GUI.
For what it’s worth to anyone reading, no additional software is technically necessary. The macOS native Terminal.app has the capability, though it’s admittedly not as user friendly as a GUI app.
Code:
sftp user@host
So for most, sftp admin@192.168...
 
Could someone please post pixelserv stats?

I'm interested in:
tav - average processing time (per request)
tmx - longest processing time (per request)

I'm actually surprised that such a tiny package like pixelserv-tls also has support for
zrt - TLS 1.3 Early Data aka 0-RTT - super cool!

View attachment 20457

Code:
pixelserv-tls 2.3.1 (compiled: Dec 13 2019 20:33:42 flags: tfo tls1_3) options: 192.168.50.3

uts    0d 22:34    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    7    number of active service threads
kmx    24    maximum number of service threads
kvg    1.39    average number of requests per service thread
krq    25    max number of requests by one service thread
req    3511    total # of requests (HTTP, HTTPS, success, failure etc)
avg    608 bytes    average size of requests
rmx    15473 bytes    largest size of request(s)
tav    8 ms    average processing time (per request)
tmx    75 ms    longest processing time (per request)
slh    1441    # of accepted HTTPS requests
slm    47    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but not usable)
slc    869    # of dropped HTTPS requests (client disconnect without sending any request)
slu    1088    # of dropped HTTPS requests (other TLS handshake errors)
v13    1441    slh/slc break-down: TLS 1.3
v12    769    slh/slc break-down: TLS 1.2
v10    100    slh/slc break-down: TLS 1.0
zrt    81    slh break-down: TLS 1.3 Early Data aka 0-RTT
 
Code:
pixelserv-tls 2.3.1 (compiled: Dec 13 2019 20:33:42 flags: tfo tls1_3) options: 192.168.50.3

uts    0d 22:34    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    7    number of active service threads
kmx    24    maximum number of service threads
kvg    1.39    average number of requests per service thread
krq    25    max number of requests by one service thread
req    3511    total # of requests (HTTP, HTTPS, success, failure etc)
avg    608 bytes    average size of requests
rmx    15473 bytes    largest size of request(s)
tav    8 ms    average processing time (per request)
tmx    75 ms    longest processing time (per request)
slh    1441    # of accepted HTTPS requests
slm    47    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but not usable)
slc    869    # of dropped HTTPS requests (client disconnect without sending any request)
slu    1088    # of dropped HTTPS requests (other TLS handshake errors)
v13    1441    slh/slc break-down: TLS 1.3
v12    769    slh/slc break-down: TLS 1.2
v10    100    slh/slc break-down: TLS 1.0
zrt    81    slh break-down: TLS 1.3 Early Data aka 0-RTT

Thanks @Makaveli, for some reason I'm still getting quite a bit of slu's even after updating pixelserv-tls to 2.3.1
Your tav is 8ms where mine is quite high - 47ms? I can live with 8ms but 47ms seems a bit high to me. Does anyone know what affects the tav processing? Is it the router CPU?

Also my ash - slu break-down: # of shutdown by clients after ServerHello seems quite high? ServerHello would be the very first handshake so I'm surprised to see high number here?

Appreciate if someone with better knowledge (than me) could give me some pointers on how to improve my stats.

Here are my stats after one day:

Code:
pixelserv-tls 2.3.1 (compiled: Dec 13 2019 20:33:31 flags: tls1_3) options: 192.168.1.2

uts    0d 15:16    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    7    maximum number of service threads
kvg    19.00    average number of requests per service thread
krq    158    max number of requests by one service thread
req    25811    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1262 bytes    average size of requests
rmx    31760 bytes    largest size of request(s)
tav    47 ms    average processing time (per request)
tmx    2085 ms    longest processing time (per request)
slh    501    # of accepted HTTPS requests
slm    65    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but not usable)
slc    138    # of dropped HTTPS requests (client disconnect without sending any request)
slu    25103    # of dropped HTTPS requests (other TLS handshake errors)
v13    608    slh/slc break-down: TLS 1.3
v12    2    slh/slc break-down: TLS 1.2
v10    29    slh/slc break-down: TLS 1.0
zrt    0    slh break-down: TLS 1.3 Early Data aka 0-RTT
uca    0    slu break-down: # of unknown CA reported by clients
ucb    17322    slu break-down: # of bad certificate reported by clients
uce    3812    slu break-down: # of unknown cert reported by clients
ush    3872    slu break-down: # of shutdown by clients after ServerHello
 
Which version of testssl.sh are you using?

I tried 2.9.5-8 (via brew install) on a MacBook Pro, but the highest Safari simulated is "Safari 10 for OS X 10.12" (and "Safari 7 for iOS 7.1"); rather outdated...

Yeah, don't use the brew version as it is not updated very frequently.
As per the github repo installation instructions, just do git clone and you will get the very latest, see below:

Code:
git clone --depth 1 https://github.com/drwetter/testssl.sh.git

Cloning into 'testssl.sh'...
remote: Enumerating objects: 79, done.
remote: Counting objects: 100% (79/79), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 79 (delta 12), reused 21 (delta 6), pack-reused 0
Unpacking objects: 100% (79/79), done.

cd testssl.sh

./testssl.sh --client-simulation 192.168.1.2

###########################################################
    testssl.sh       3.0rc6 from https://testssl.sh/dev/
    (fa5bb18 2019-12-24 11:47:41 -- )
###########################################################
 
Thanks @Makaveli, for some reason I'm still getting quite a bit of slu's even after updating pixelserv-tls to 2.3.1
Your tav is 8ms where mine is quite high - 47ms? I can live with 8ms but 47ms seems a bit high to me. Does anyone know what affects the tav processing? Is it the router CPU?

Also my ash - slu break-down: # of shutdown by clients after ServerHello seems quite high? ServerHello would be the very first handshake so I'm surprised to see high number here?

Appreciate if someone with better knowledge (than me) could give me some pointers on how to improve my stats.

Here are my stats after one day:

Code:
pixelserv-tls 2.3.1 (compiled: Dec 13 2019 20:33:31 flags: tls1_3) options: 192.168.1.2

uts    0d 15:16    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    7    maximum number of service threads
kvg    19.00    average number of requests per service thread
krq    158    max number of requests by one service thread
req    25811    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1262 bytes    average size of requests
rmx    31760 bytes    largest size of request(s)
tav    47 ms    average processing time (per request)
tmx    2085 ms    longest processing time (per request)
slh    501    # of accepted HTTPS requests
slm    65    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but not usable)
slc    138    # of dropped HTTPS requests (client disconnect without sending any request)
slu    25103    # of dropped HTTPS requests (other TLS handshake errors)
v13    608    slh/slc break-down: TLS 1.3
v12    2    slh/slc break-down: TLS 1.2
v10    29    slh/slc break-down: TLS 1.0
zrt    0    slh break-down: TLS 1.3 Early Data aka 0-RTT
uca    0    slu break-down: # of unknown CA reported by clients
ucb    17322    slu break-down: # of bad certificate reported by clients
uce    3812    slu break-down: # of unknown cert reported by clients
ush    3872    slu break-down: # of shutdown by clients after ServerHello
Your router model makes a good bit of difference as far as tav goes. The AC86 and AX88 perform noticeably better than the older models. As for the slu situation, the biggest factor is what domains you’re blocking and how often you’re hitting them. As a for instance, if you’re blocking graph.instagram.com and use the app with any frequency, your slu will skyrocket.
 
Your router model makes a good bit of difference as far as tav goes. The AC86 and AX88 perform noticeably better than the older models. As for the slu situation, the biggest factor is what domains you’re blocking and how often you’re hitting them. As a for instance, if you’re blocking graph.instagram.com and use the app with any frequency, your slu will skyrocket.

Thanks @jrmwvu04 - that makes perfect sense now. The kids iPhones are hitting snapchat and instagram like there's no tomorrow, so that would explain what you mentioned above.

I use R7000 with WiFi disabled and Unifi NanoHD and it does the job for now, however I might need to upgrade to some of the newer ASUS models soon.
 
Thanks @jrmwvu04 - that makes perfect sense now. The kids iPhones are hitting snapchat and instagram like there's no tomorrow, so that would explain what you mentioned above.
At the meeting of the minds on this topic it was decided that the apps carry a certificate payload and when they reach out to their server and it gets routed to pixelserv instead, the certificates don’t match and the handshake fails. There’s no way around that but to change your configuration such that the offending domain doesn’t point to pixelserv, such as sending it to 0.0.0.0 or just whitelisting it.

Personally, I don’t find it to be worth the trouble. Performance with the failed handshakes seems fine to me and since it currently passes the @ColinTaylor WCT , I have no reason to investigate further at this time.
 
Could someone please post pixelserv stats?

I'm interested in:
tav - average processing time (per request)
tmx - longest processing time (per request)

I'm actually surprised that such a tiny package like pixelserv-tls also has support for
zrt - TLS 1.3 Early Data aka 0-RTT - super cool!

View attachment 20457
pixelserv-tls.png
 
Also here are the steps for the manual update of pixelserv-tls in case someone needs assistance until it gets updated in the entware repos.

Code:
ssh to your router and find pixelserv-tls
admin@yourrouter:/tmp/home/root# which pixelserv-tls
/opt/bin/pixelserv-tls

close your ssh session

Download the latest pixelserv-tls from github on your local machine: https://github.com/kvic-z/pixelserv-tls/releases/tag/v2.3.1  - choose the version compatible with your router

wget https://github.com/kvic-z/pixelserv-tls/releases/download/v2.3.1/pixelserv-tls.2.3.1.Entware-ng.armv7softfloat.zip

create new dir: mkdir pixelserv

unzip the archive: unzip pixelserv-tls.2.3.1.Entware-ng.armv7softfloat.zip -d pixelserv

cd to pixelserv/dist and rename/move the file

mv pixelserv-tls.arm.ent.performance.dynamic ~/Downloads/pixelserv/pixelserv-tls

upload the file to your router /tmp dir first
scp pixelserv-tls admin@192.168.1.1:/tmp/

ssh to your router and copy the file in the correct directory (remember /opt/bin/pixelserv-tls)
cp /tmp/pixelserv-tls /opt/bin/pixelserv-tls

check the permissions: ls -la /opt/bin/pixelserv-tls
I used /opt/etc/init.d/S80pixelserv-tls to stop and start.
I did some extra steps before starting pixelserv-tls, however it only makes sense to do these steps after you upgrade to diversion 4.1.8.
Backup your current key and cert from entware/var/cache/pixelserv (Pixelserv cache directory)
Delete all of the old certs created by the old key and cert in your Pixelserv cache directory.
Delete the old key and cert in your Pixelserv cache directory.
Run Asad Ali's instructions to generate an Apple-compliant key and certificate. I ran this from a directory on my external drive and copied the results to the Pixelserv cache directory.
Code:
cat /etc/openssl.cnf > /jffs/openssl.cnf
sed -i "/\[ v3_ca \]/aextendedKeyUsage = serverAuth" /jffs/openssl.cnf
openssl genrsa -out ca.key 2048
openssl req -key ca.key -new -x509 -days 825 -sha256 -extensions v3_ca -out ca.crt -subj "/CN=Pixelserv CA" -config /jffs/openssl.cnf
rm /jffs/openssl.cnf
The following from Kvic makes it easy to use the pixelserv-tls key and cert for the router GUI https
Code:
sh -c "$(wget -qO - https://kazoo.ga/pixelserv-tls/config-webgui.sh)"
Install ca.crt in Windows and iOS devices.
 
Last edited:
As for the slu situation,
Also, devices where you can't import a cert at all, like IP cams, doorbells, amazon stuff, tvs, rokus. . . .
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top