eclp
Senior Member
That's a calming/peaceful image you've put in my mind! Thank you.
I think he could let us share in this view. Especially when we still have to spend some time waiting for Diversion 4.0.8.
That's a calming/peaceful image you've put in my mind! Thank you.
Let's just say I have this view, more peripheral and not from the Google's view higher up. I live in one of the houses in this picture but don't see Lake Lucerne (Vierwaldstättersee) as it is behind the hills.I think he could let us share in this view. Especially when we still have to spend some time waiting for Diversion 4.0.8.
I see where this is coming from but have yet to figure out how to prevent amtm from closing at the same time when exiting Diversion.I run from AMTM, chose Diversion, then f follow log file, then Ctrl-E to exit, then when I choose E to exit back to AMTM, it dumps me to command line. It is repeatable for me, I've run this six times and it happens every time.
Noted.Can I offer a suggestion about the update entware part? I appreciate the warning you have included about updating diversion within diversion. The same would be true of stubby, which I note very carefully only updates the packages it uses. But I think it would be useful to warn people that updating anything this way may alter configuration files and the init.d scripts, which should be backed up before hand and checked after.
Thank you, as I stated it is no big deal, just wanted you to be aware if you were not. A simple up arrow in terminal brings up amtm from ash_history.I see where this is coming from but have yet to figure out how to prevent amtm from closing at the same time when exiting Diversion.
Can I offer a suggestion about the update entware part? I appreciate the warning you have included about updating diversion within diversion. The same would be true of stubby, which I note very carefully only updates the packages it uses. But I think it would be useful to warn people that updating anything this way may alter configuration files and the init.d scripts, which should be backed up before hand and checked after.
The reason I added the cautionary text is that when Entware (through amtm or manually) updates pixelserv-tls it did overwrite the S80 startscript and causes(ed) pixelserv-tls to not start. When doing it through Diversion, I make sure that won't happen.I’m presuming the problem is something like:
Diversion and one or 2 other packages under AMTM’s aegis use some Entware packages. So there’s a pissible conflict: an update of eg Diversion might also update a dependant Entware package; on the other hand, an Entware update might also unintentionally update a package that Diversion uses and cause problems.
So, would the right thing to do be: if you don’t knowingly use Entware, never update it (through AMTM or any other method). Only update the programs eg Diversion that you use. And if you do use Entware eg in specialist scripts, then beware: updating Entware itself might have unintended consequences on eg Diversion.
What percentage of all that has any bearing on reality?
Install htop in Entware and see which process is taking up the cpu.I installed Stubby an hour ago, since then CPU is at 100% all the time. The router is AC68U, Merlin 384.8-2 with amtm 1.8, Diversion 4.0.7., Skynet 6.7.3 and now Stubby DNS v1.0.8
What gives?
Hi,
sorry for asking, but some things are just not clear for me...
At the moment, I have amtm, Diversion, Skynet, htop and Stubby DNS installed on my router. 2 GB SWAP on my USB stick.
Question(s):
1.) Are those entware apps on jffs or on SWAP drive?
2.) If I upgrade my router with a MAJOR update (for example 380.xx to 384.xx...) it is clear to configure the router from scratch... Still, can I migrate those apps somehow or do I also have to install all of them once more from scratch? If no, how do I backup these apps?
Hopefully I am clear with what I want...
Thanks!
DNSCrypt is a stubby alt yes.
please help me understand these apps
dnscrypt is equivalent/included in stubby
pixelserv is equivalent/included in skynet
so i really don't need those two, right?
pixelserv works with Diversion to block ads, not to do with SkyNET.
I believe the amtm menu version is newer than the Diversion install version. Same with some entware packages. It’s reccommended to use the versions installed with diversion and not update independently. But amtm gives you the options to do so if you choose.i know that diversion and skynet coordinate their lists, are not codependent,
and block ads using different methods thus they are not redundant.
but pixelserv is supposed to be included during diversion's install
Use a blocklist: Diversion. Note: This Ad-blocker includes the installation of pixelserv-tls
so is the pixelserv here in amtm's menu for stand alone use only?
but is actuality already installed because i have the latest diversion running?
or is amtm clearly indicating i somehow did NOT install pixelserv with diversion.
if i still need to install pixelserv with diversion, then how exactly has
diversion NOT been functional, since it seems to be working just fine.
for a while i was running diversion alone, and it clearly blocked ads.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!