What's new

AdGuardHome [RELEASE] Asuswrt-Merlin-AdGuardHome-Installer (AMAGHI)

  • 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!

I havent had a chance to mess with this since the other day, but figured out what was going on. I use dual-wan for failover. When the second line is considered "hot", for some reason it shows wan_ipaddr as a private. But what Im actually using is wan0_ipaddr , sorry I should have checked this more. The second failover connection is not bridged, ie double-nat.
admin@RT-AX86U-D7D0:/tmp/mnt/AX/entware/etc/AdGuardHome# nvram get wan_ipaddr
192.168.10.189
admin@RT-AX86U-D7D0:/tmp/mnt/AX/entware/etc/AdGuardHome# nvram get wan0_ipaddr
100.119.236.128
Do me a favor what does

Code:
route | grep 'eth0'

show for you?
 
Do me a favor what does

Code:
route | grep 'eth0'

show for you?
admin@RT-AX86U-D7D0:/tmp/home/root# route | grep 'eth0'
default 100.64.0.1 0.0.0.0 UG 0 0 0 eth0
1.1.1.1 100.64.0.1 255.255.255.255 UGH 1 0 0 eth0
8.8.8.8 100.64.0.1 255.255.255.255 UGH 1 0 0 eth0
34.120.255.244 * 255.255.255.255 UH 0 0 0 eth0
100.64.0.0 * 255.192.0.0 U 0 0 0 eth0
100.64.0.1 * 255.255.255.255 UH 0 0 0 eth0
192.168.100.1 * 255.255.255.255 UH 0 0 0 eth0
 
admin@RT-AX86U-D7D0:/tmp/home/root# route | grep 'eth0'
default 100.64.0.1 0.0.0.0 UG 0 0 0 eth0
1.1.1.1 100.64.0.1 255.255.255.255 UGH 1 0 0 eth0
8.8.8.8 100.64.0.1 255.255.255.255 UGH 1 0 0 eth0
34.120.255.244 * 255.255.255.255 UH 0 0 0 eth0
100.64.0.0 * 255.192.0.0 U 0 0 0 eth0
100.64.0.1 * 255.255.255.255 UH 0 0 0 eth0
192.168.100.1 * 255.255.255.255 UH 0 0 0 eth0
I was actually looking at that command earlier also, wanting to setup a notification of when failsafe kicked over.
 
admin@RT-AX86U-D7D0:/tmp/home/root# route | grep 'eth0'
default 100.64.0.1 0.0.0.0 UG 0 0 0 eth0
1.1.1.1 100.64.0.1 255.255.255.255 UGH 1 0 0 eth0
8.8.8.8 100.64.0.1 255.255.255.255 UGH 1 0 0 eth0
34.120.255.244 * 255.255.255.255 UH 0 0 0 eth0
100.64.0.0 * 255.192.0.0 U 0 0 0 eth0
100.64.0.1 * 255.255.255.255 UH 0 0 0 eth0
192.168.100.1 * 255.255.255.255 UH 0 0 0 eth0
What about

Code:
ip -4 a | grep eth0
 
What about

Code:
ip -4 a | grep eth0
admin@RT-AX86U-D7D0:/tmp/home/root# ip -4 a | grep eth0
11: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000
inet 100.119.236.128/10 brd 100.127.255.255 scope global eth0
 
I was actually looking at that command earlier also, wanting to setup a notification of when failsafe kicked over.
I imagine something like

Code:
route | grep 'eth0' | grep 'default' | grep -oE '\b^(((10|127)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|(((172\.(1[6-9]|2[0-9]|3[0-1]))|(192\.168))(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}))$\b'

should provide a good indication of when you are no longer in "kansas" so to speak. :cool:
 
I imagine something like

Code:
route | grep 'eth0' | grep 'default' | grep -oE '\b^(((10|127)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|(((172\.(1[6-9]|2[0-9]|3[0-1]))|(192\.168))(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}))$\b'

should provide a good indication of when you are no longer in "kansas" so to speak. :cool:
Thats a hell of grep, but that returns nothing like it should. Sorry for all that work.
 
Thats a hell of grep, but that returns nothing like it should. Sorry for all that work.
So the thought is that when you are on fail safe, you should notice your default route switch to the private address the failsafe is given. Thus the grep command will print the private address in this instance. You obviously would want to test this theory.
 
So the thought is that when you are on fail safe, you should notice your default route switch to the private address the failsafe is given. Thus the grep command will print the private address in this instance.
correct, and well it would be correct at that point that its double-nat in my situation.
 
correct, and well it would be correct at that point that its double-nat in my situation.
the grep should be able to be simplified down to

Code:
route | grep 'default' | grep -oE '\b^(((10|127)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|(((172\.(1[6-9]|2[0-9]|3[0-1]))|(192\.168))(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}))$\b'
 
Hi
From amtm I see an update of AGH bin. I try the update but the warning always remains.
My router is rt-ac86u with the last rmerlin firmware.
How can i solve?

Thanks
 

Attachments

  • 1893FA67-CAFE-47A7-8287-6D49AFC36163.jpeg
    1893FA67-CAFE-47A7-8287-6D49AFC36163.jpeg
    15.8 KB · Views: 89
That's not an upgrade, that's a downgrade.

You must be on a dev version.
 
That's not an upgrade, that's a downgrade.

You must be on a dev version.
Sorry, it is likely that I have made an incorrect update. Can i go back or should i keep this version?

Thanks
 
Sorry, it is likely that I have made an incorrect update. Can i go back or should i keep this version?

Thanks
You can always run the update function in the adguardhome installer. You should have no issue changing between branches as long as the branch you are coming from or switching to doesn't drastically change options inside the .yaml file. My suggestion to anyone running adguardhome is to pick a branch and stick with it because branches are updated in accordance to the branch they are on. Also, when deciding to switch between branches, I highly recommend users making backups using the installer. In instances like this, a backup could resolve potential issues presented between updates and switching branches while still allowing users to go back if they run into a problem. thus preventing the possibility of conflicts.

Stable ----> only gets updated on stable releases
Beta----> only gets updated on beta releases
Edge----> gets updated whenever the builds from master are built daily

Now the update detection of AdGuardHome via AMTM may be an issue that @thelonelycoder will have to look into when he has time. It appears there may be a tiny glitch in the logic of update checks for AdGuardHome using AMTM.

But first as a test @StefanoN can you run option uu via amtm menu? give it a few seconds to run. it may take a moment because it updates all your AMTM add-on auxiliary files. This is just to confirm you are not by accident using an older adguardhome amtm auxiliary file.
 
Last edited:
You can always run the update function in the adguardhome installer. You should have no issue changing between branches as long as the branch you are coming from or switching to doesn't drastically change options inside the .yaml file. My suggestion to anyone running adguardhome is to pick a branch and stick with it because branches are updated in accordance to the branch they are on. Also, when deciding to switch between branches, I highly recommend users making backups using the installer. In instances like this, a backup could resolve potential issues presented between updates and switching branches while still allowing users to go back if they run into a problem. thus preventing the possibility of conflicts.

Stable ----> only gets updated on stable releases
Beta----> only gets updated on beta releases
Edge----> gets updated whenever the builds from master are built daily

Now the update detection of AdGuardHome via AMTM may be an issue that @thelonelycoder will have to look into when he has time. It appears there may be a tiny glitch in the logic of update checks for AdGuardHome using AMTM.

But first as a test @StefanoN can you run option uu via amtm menu? give it a few seconds to run. it may take a moment because it updates all your AMTM add-on auxiliary files. This is just to confirm you are not by accident using an older adguardhome amtm auxiliary file.
Hi
Sorry for the delay. After the option uu.. same result on screen.

Thanks
 
Yea it is a glitch with the update detection on adguardhome addon auxiliary file. Can't fix it until next patch for amtm. Just ignore it or switch branches using the installer.
Hi
Good I can wait. :)
Thanks for the support.
 
Hi
Good I can wait. :)
Thanks for the support.
Turns out the issue isn't created by AdguardHome installer or AMTM, but Adguardhome for not properly updating their release tag. Currently, the release version available is yours, but they have not updated the github tags to reflect this information, thus why you see the lesser version offered as an update.


Any one can follow the issue I opened right here:

 
Last edited:
I just wanted to let everyone know I took the time to attempt to add us to the list of adguardhome supported platforms.


We will see if we get a bite, but either way I want everyone to know I intend to keep this running either way. I appreciate you all!
And most importantly I want to give a dedicated thank you to @RMerlin, @gspannu , @thelonelycoder , @chongnt , @dave14305 , @Jack Yaz , @juched , @TheMorpN , @garycnew , @cptnoblivious , @ColinTaylor , @octopus , @Zastoff , @Viktor Jaep , and @L&LD for all your contribution to anything on SNB. You guys are great! And thank you for all your contributions!
 
Last edited:
For any one wishing to update... I have made several code improvements at the observations of @Markfree 's logs. Also, I have implemented several other code improvements by adding a way for users to reconfigure, which will put the user back at the initial inputs without any potential snapfu additions that may break the users general experience. It also will back up the previous configuration in the process, thus an option is present for the user to use a prevous configuration if they decide they want to go back!. I hope these options will help anyone having accidentally snapful there setup by minimizing the need to reinstall.

-Thank all of you for your support.
 

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