Diversion Diversion - the Router Ad-Blocker

[Butterfly Bones]

Ubuntu is affected by this also?

I have a laptop with it and didn't notice any issues while on previous versions

I screwed up, it is Debian, I used to run it, and keep getting my brain twisted.

https://kazoo.ga/pixelserv-tls/

Support the new TLS requirements from Debian & Apple Inc

 

[^Tripper^]

Updated and regenerated pixelserv root CA. I must’ve borked something as pixelserv seems broken now. Was running 2.3.1 without any issues, updated diversion and not being able to leave things alone, I regenerated the root CA. Now pixelserv stats is showing zero accepted https requests. All others are “dropped HTTPS requests (other TLS handshake errors)”. Am on a 86U, on merlin’s 384.14, with new ca.crts imported on Apple clients.

I can easily nuke the router and start afresh but I figure I better hold off on that and report my results should anyone need any info or would like me to try anything. Like a new hobby for instance.

 

[Treadler]

Updated and regenerated pixelserv root CA. I must’ve borked something as pixelserv seems broken now. Was running 2.3.1 without any issues, updated diversion and not being able to leave things alone, I regenerated the root CA. Now pixelserv stats is showing zero accepted https requests. All others are “dropped HTTPS requests (other TLS handshake errors)”. Am on a 86U, on merlin’s 384.14, with new ca.crts imported on Apple clients.

I can easily nuke the router and start afresh but I figure I better hold off on that and report my results should anyone need any info or would like me to try anything. Like a new hobby for instance.

Hmmm......
I was going to have another crack at putting 2.3.1 on this afternoon. Maybe I’ll just hold that thought. (& get a new hobby.......)

 

[thelonelycoder]

Updated and regenerated pixelserv root CA. I must’ve borked something as pixelserv seems broken now. Was running 2.3.1 without any issues, updated diversion and not being able to leave things alone, I regenerated the root CA. Now pixelserv stats is showing zero accepted https requests. All others are “dropped HTTPS requests (other TLS handshake errors)”. Am on a 86U, on merlin’s 384.14, with new ca.crts imported on Apple clients.

I can easily nuke the router and start afresh but I figure I better hold off on that and report my results should anyone need any info or would like me to try anything. Like a new hobby for instance.

Did you purge the domain certs after regenerating the root CA?

 

[^Tripper^]

Did you purge the domain certs after regenerating the root CA?

Yup.

 

[Mircica]

Dear @lonelycoder
I am getting this:

using temporary pgl.yoyo.org file to lower memory usage while updating
remote file same: using local file
https://pgl.yoyo.org/adservers/serv...&showintro=0&mimetype=plaintext&useip=0.0.0.0
writing temporary pgl.yoyo.org blocking list

preparing temporary whitelist
preserving assembled hardcoded whitelist
updated /jffs/shared-Diversion-whitelist

downloading Small blocking list, 1 (omitting -1 duplicate) file(s)
using 192.168.1.2 as blocking IP
update of Small blocking list failed completely, using previous file

mv: can't rename '/opt/share/diversion/backup/inuse*': No such file or directory

Is it OK or not? inuse*?

Also if I use this command:
opkg install pixelserv-tls
I am getting this:
Package pixelserv-tls (2.3.0-1) installed in root is up to date.

 

[thelonelycoder]

downloading Small blocking list, 1 (omitting -1 duplicate) file(s)
using 192.168.1.2 as blocking IP
update of Small blocking list failed completely, using previous file

mv: can't rename '/opt/share/diversion/backup/inuse*': No such file or directory

Cant update the blocking list if there's no hosts list URL left. Check in b, 1, 2. It'll show an empty file.

Also if I use this command:
opkg install pixelserv-tls
I am getting this:
Package pixelserv-tls (2.3.0-1) installed in root is up to date.

You'll have to wait until the Entware team releases the new version.

 

[Centrifuge]

Did you purge the domain certs after regenerating the root CA?

Is that for older versions of pixelserve? Per pixelserve site:

Caution: If you're upgrading from v2.2.1-1 or earlier, remember to delete all certificate files except 'ca.crt' and 'ca.key' in '/opt/var/cache/pixelserv' and then restart pixelserv-tls.

After manually upgrading from 2.3.0 to 2.3.1, I had a few glitches, washingtonpost site coudn't be found, amtm returned a "bad number" when checking for updates, got a 404 on trying to update scmerlin script, and update hung on checking for a Skynet update. Followed dnmasq nothing popped out, rebooted, ate dinner, now things seem to be working okay.

 

[bluepoint]

Yup.

Can you open this verizon home page?

 

[thelonelycoder]

Is that for older versions of pixelserve? Per pixelserve site:

Caution: If you're upgrading from v2.2.1-1 or earlier, remember to delete all certificate files except 'ca.crt' and 'ca.key' in '/opt/var/cache/pixelserv' and then restart pixelserv-tls.

After manually upgrading from 2.3.0 to 2.3.1, I had a few glitches, washingtonpost site coudn't be found, amtm returned a "bad number" when checking for updates, got a 404 on trying to update scmerlin script, and update hung on checking for a Skynet update. Followed dnmasq nothing popped out, rebooted, ate dinner, now things seem to be working okay.

You likely did omit a step or something went wrong. That‘s why I encourage users to wait until Entware releases the official pixelserv-tls v2.3.1 updated package.
... Unless you know exactly what you‘re doing, of course.
The latest Entware release version is indeed v2.2.1-1.

 

[SomeWhereOverTheRainBow]

new thing to point out .... Diversion has apparently left its parent installer in Jffs after installation has completed.

#!/bin/sh
#bof

# Diversion is free to use under the GNU General Public License version 3 (GPL-3.0)
# https://opensource.org/licenses/GPL-3.0

# Proudly coded by thelonelycoder
# Copyright (c) 2016-2019 thelonelycoder - All Rights Reserved
#................. you can guess the rest.

 

[thelonelycoder]

new thing to point out .... Diversion has apparently left its parent installer in Jffs after installation has completed.

#!/bin/sh
#bof

# Diversion is free to use under the GNU General Public License version 3 (GPL-3.0)
# https://opensource.org/licenses/GPL-3.0

# Proudly coded by thelonelycoder
# Copyright (c) 2016-2019 thelonelycoder - All Rights Reserved
#................. you can guess the rest.

??
Can you elaborate? Also, that header is from an older version.

 

[SomeWhereOverTheRainBow]

??
Can you elaborate? Also, that header is from an older version.

I used the install option from amtm and this was in /jffs/scripts afterwards (btw i decided to clean install since the adaption of new certificate and what not).

 

[thelonelycoder]

I used the install option from amtm and this was in /jffs/scripts afterwards (btw i decided to clean install since the adaption of new certificate and what not).

I see, is the file still there, the version numbers would be of interest a bit further down.

 

[thelonelycoder]

I used the install option from amtm and this was in /jffs/scripts afterwards (btw i decided to clean install since the adaption of new certificate and what not).

Diversion initially places itself into the /home/root folder until the structure is created in /opt during installation.
At no point is the Diversion main file placed in the /jffs/ folder structure. This must be a remnant of your own doing, with an older version than the current 4.1.7.

 

[^Tripper^]

So poking around my devices yields an interesting result; only devices updated to iOS 13 and macOS 10.15 are giving me these errors, older devices on 10.13 for example are fine. Can only guess its something to do with the apple requirements. My best guess at this point.

 

[thelonelycoder]

So poking around my devices yields an interesting result; only devices updated to iOS 13 and macOS 10.15 are giving me these errors, older devices on 10.13 for example are fine. Can only guess its something to do with the apple requirements. My best guess at this point.

Did you install and confirm the ca.crt in Settings/Profile on the iOS devices?
I'm not sure what Settings/About/Certificate Trust Settings does, but I have it enabled as well.

 

[^Tripper^]

Did you install and confirm the ca.crt in Settings/Profile on the iOS devices?
I'm not sure what Settings/About/Certificate Trust Settings does, but I have it enabled as well.

Yup. The toggle is set to “trust”.

 

[SomeWhereOverTheRainBow]

Diversion initially places itself into the /home/root folder until the structure is created in /opt during installation.
At no point is the Diversion main file placed in the /jffs/ folder structure. This must be a remnant of your own doing, with an older version than the current 4.1.7.

I deleted it, but i think amtm did it. at no point have i ever put a diversion install inside jffs. that would be silly when all i have to do is hit option 1 in amtm to install diversion.

 

[Asad Ali]

Did you install and confirm the ca.crt in Settings/Profile on the iOS devices?
I'm not sure what Settings/About/Certificate Trust Settings does, but I have it enabled as well.

I'll need to do further testing with 1024bit key but Apple's guidelines are pretty clear on this issue:

"TLS server certificates and ISSUING CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS."


https://support.apple.com/en-us/HT210176