[DSL-AC68U] AsusWrt Merlin builds for DSL routers

[Jumpstarter]

Yea I just updated and gnutonwrt is running good. It seems to reboot faster. I hope gnuton keeps up the good work.

 

[kernol]

Looks like we may have found a mini-Merlin in GNUton

Every release version I have applied to my DSL-AC68U has worked flawlessly - starting with a dirty upgrade from stock firmware [384-10-2] to GNUton4 and now dirty flash to 384.11_2-gnuton1.

Time for him to open a Paypal donation link so we can begin to show our appreciation.

 

[sugar0]

Time for him to open a Paypal donation link so we can begin to show our appreciation.

I agree! Work must always be compensated in a way or another. That takes time that devs could actually spend in other manners

 

[DaVoodoo]

Time for him to open a Paypal donation link so we can begin to show our appreciation.

I agree 100%. Let us give him his due.

 

[GNUton]

Hi guys!
thanks for the nice words. I will evaluate the chance to accept donations.

In any case I have just released a new firmware image, you should now correctly get notifications when a new stable image is released.
As always please let me know if there is anythig which doesn't work properly.
Cheers
Antono

 

[kernol]

Hi guys!
thanks for the nice words. I will evaluate the chance to accept donations.

In any case I have just released a new firmware image, you should now correctly get notifications when a new stable image is released.
As always please let me know if there is anythig which doesn't work properly.
Cheers
Antono

Hi Antonio - one thing I have noticed is that free space within NVRAM on the DSL-AC68U is getting less and less with each new build - so may become a problem with "dirty flashes" in the future.
In that case @L&LD M&M processes may become necessary - with Factory Reset option including clearing the NVRAM?
If this is not a concern - ignore ... I'm a non-coder - so may be barking up the wrong tree .

 

[GNUton]

Hi Antonio - one thing I have noticed is that free space within NVRAM on the DSL-AC68U is getting less and less with each new build - so may become a problem with "dirty flashes" in the future.
In that case @L&LD M&M processes may become necessary - with Factory Reset option including clearing the NVRAM?
If this is not a concern - ignore ... I'm a non-coder - so may be barking up the wrong tree .

That's a good observation! Actually I'm adding new features and these new features (eg firmware update checks) set new vars in the nvram.
If you see there is something really wasting nvram space please let me know. As for now I think it's okay and under control.
Cheers!

 

[kernol]

That's a good observation! Actually I'm adding new features and these new features (eg firmware update checks) set new vars in the nvram.
If you see there is something really wasting nvram space please let me know. As for now I think it's okay and under control.
Cheers!

Space left in my NVRAM was only 4028 - so I ran this code in SSH terminal to clean up ...

for line in `nvram show | grep =$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

Free NVRAM space after running was 15303 - much better .

 

[kernol]

Another "tip" for those updating from one version of GNUton to the next on the DSL-AC68U with several of the scripts provided by @thelonelycoder through his awesome utility "amtm" [latest version please ] is to perform Webgui "Eject USB" BEFORE you flash the new firmware.

This effectively shuts down the extra's and releases much needed RAM for the flash process.

I don't actually remove the USB after "Eject USB" - no need in my view - you just want the extra free RAM for the Flash and reboot process.

If going from 384.10-2 base firmware to 384.11-2 base you may be best advised to uninstall Stubby DNS and ntpMerlin FIRST [before Webgui Eject Disk] if you plan to use the 384.11-2 firmware based features for these two utilities.

 

[sugar0]

i'm noticing a strange behavior today. CPU usage show high and intermittent usage on the dashboard but with a "top" command i see little usage:

EDIT: the bandwitch today is really low (<2mbit .. i usage 4g). Could it be that?

 

[dukehole66]

Ladies & gents,
I'm looking for some testers.. new alpha available based on 384.11_2.
Beside the upstream changes please test if the firmware check works: https://github.com/gnuton/asuswrt-merlin.ng/issues/15
Note: factory reset after flashing the new firmware is needed to get the new feature work

Image available here: https://github.com/gnuton/asuswrt-merlin.ng/releases/tag/384.11_2-gnuton1_alpha1
Thanks a lot

If possible in the future DSL AC87VG as well, then i can test it for you no problem.

 

[L&LD]

If possible in the future DSL AC87VG as well, then i can test it for you no problem.

Not possible, if I recall correctly. Search in this thread, the '87VG is running different hardware and different firmware too.

 

[sugar0]

i'm noticing a strange behavior today. CPU usage show high and intermittent usage on the dashboard but with a "top" command i see little usage:

EDIT: the bandwitch today is really low (<2mbit .. i usage 4g). Could it be that?

I constatly have this [mtdblock3] spike even ate 30-40%. what could be the cause?
If i dont stop the VPN i got speeds of like 1mb or lower!
Here's also the log:

May 27 22:34:16 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:34:19 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:34:25 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:34:26 ovpn-client1[4313]: FRAG TTL expired i=0
May 27 22:34:26 ovpn-client1[4313]: FRAG TTL expired i=17
May 27 22:34:31 ovpn-client1[4313]: FRAG TTL expired i=9
May 27 22:34:43 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:34:43 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)
May 27 22:34:44 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:34:46 ovpn-client1[4313]: FRAG TTL expired i=20
May 27 22:34:49 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:34:51 ovpn-client1[4313]: FRAG TTL expired i=2
May 27 22:34:56 ovpn-client1[4313]: FRAG TTL expired i=8
May 27 22:35:02 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:35:11 ovpn-client1[4313]: FRAG TTL expired i=15
May 27 22:35:13 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:35:13 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)
May 27 22:35:21 ovpn-client1[4313]: FRAG TTL expired i=21
May 27 22:35:22 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:35:44 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:35:44 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)
May 27 22:35:46 ovpn-client1[4313]: FRAG TTL expired i=0
May 27 22:35:46 ovpn-client1[4313]: FRAG TTL expired i=24
May 27 22:36:02 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:36:13 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:36:13 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)
May 27 22:36:14 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:36:17 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:36:20 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:36:21 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:36:26 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:36:43 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:36:43 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)
May 27 22:36:49 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:37:03 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:37:11 ovpn-client1[4313]: FRAG TTL expired i=20
May 27 22:37:13 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:37:13 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)
May 27 22:37:44 ovpn-client1[4313]: Recursive routing detected, drop tun packet to [AF_INET]VPN:PORT
May 27 22:37:44 rc_service: watchdog 259:notify_rc start_cfgsync
May 27 22:37:44 custom_script: Running /jffs/scripts/service-event (args: start cfgsync)

 

[octopus]

What custom script do you use, if any?

 

[sugar0]

What custom script do you use, if any?

amtm, entware and selective routing. https://www.snbforums.com/threads/selective-routing-for-netflix.42661/page-20

All went well for 2 days at least and today i got this. Dunno if the spikes are correlated ..

 

[octopus]

Something going bad with your selective routing script for netflix. Uninstall it and reboot and test again

 

[sugar0]

restarted without the selective routing (disabled the initial script) and same error. It could also be the VPN provider fault maybe?

DHT (torrent) is certaenly causing the problem (see https://forums.openvpn.net/viewtopic.php?p=67980#p67980). I tested by killing qbittorrent and the error disappeared.
The problem now is that the vpn act weird and i can't navigate properly. I think my VPN provider is trying to "throttle" me in some way?

 

[kernol]

.....
If going from 384.10-2 base firmware to 384.11-2 base you may be best advised to uninstall Stubby DNS and ntpMerlin FIRST [before Webgui Eject Disk] if you plan to use the 384.11-2 firmware based features for these two utilities.

It seems that @GNUton has not as yet invoked two of the BEST features enabled by @RMerlin in his 384.11 firmware - namely built in Stubby with DNS over TLS [DoT] - nor the built in ntp daemon [ntpd] to enable the router to act as an internal ntp server for all clients.

Those upgrading from GNUton4 [384.10-2] can ignore the suggestion in my earlier post above ... leave them installed and they will run fine under the new firmware [DSL-AC68U_384.11_2-gnuton2_DSL_1.0.4.7]

For those relying on amtm for add-on installs from @thelonelycoder should however note that he has a firmware check built in and if 384.11 as the base firmware is detected - the Stubby Add-On by @Xentrk is not offered as a choice of install [with the "i" option in the amtm menu] - so if you want to properly secure your DNS - simply go to the Stubby add-on thread to be found here ...
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/

I imagine it will be quite a bit of work for @GNUton to enable the DoT feature as he will likely have to do so in the DSL binary code of the DSL-AC68U which until now he has probably been able to leave "as is" from Asus stock firmware. So - in the meantime just use @Xentrk 's reliable Stubby add-on.

 

[GNUton]

It seems that @GNUton has not as yet invoked two of the BEST features enabled by @RMerlin in his 384.11 firmware - namely built in Stubby with DNS over TLS [DoT] - nor the built in ntp daemon [ntpd] to enable the router to act as an internal ntp server for all clients.

Those upgrading from GNUton4 [384.10-2] can ignore the suggestion in my earlier post above ... leave them installed and they will run fine under the new firmware [DSL-AC68U_384.11_2-gnuton2_DSL_1.0.4.7]

For those relying on amtm for add-on installs from @thelonelycoder should however note that he has a firmware check built in and if 384.11 as the base firmware is detected - the Stubby Add-On by @Xentrk is not offered as a choice of install [with the "i" option in the amtm menu] - so if you want to properly secure your DNS - simply go to the Stubby add-on thread to be found here ...
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/

I imagine it will be quite a bit of work for @GNUton to enable the DoT feature as he will likely have to do so in the DSL binary code of the DSL-AC68U which until now he has probably been able to leave "as is" from Asus stock firmware. So - in the meantime just use @Xentrk 's reliable Stubby add-on.

Hi,
The DoT and ntpd should be part of the latest release of my firmware. If you are using the DSL as WAN you may have it disabled although.
There is a task https://github.com/gnuton/asuswrt-merlin.ng/issues/17 which is about tweaking the web ui in order to configure DoT for DSL as WAN.
You can already now use DoT if WAN is eth.
But if you wanna use DSL as WAN as workaround for now I think ( I have not actually tested it) you should:
1. enable dual wan
2. set DSL as primary
3. set eth0 as secondary
4. configure DoT from the webui using the setting page for the eth wan.

As for the ASUS binaries, I never do anything to them. I won't add or strip out anything from there unless it's in an experimental branch (eg: feture repeater branch)
In my understading of the DoT, it doesn't require any binary tweaking either. The way it works can be seen in the commits https://github.com/gnuton/asuswrt-merlin.ng/commit/3cc2ba9bd785edc238edbe26e4c36ff287815147
Cheers!

 

[thelonelycoder]

For those relying on amtm for add-on installs from @thelonelycoder should however note that he has a firmware check built in and if 384.11 as the base firmware is detected - the Stubby Add-On by @Xentrk is not offered as a choice of install [with the "i" option in the amtm menu] - so if you want to properly secure your DNS - simply go to the Stubby add-on thread to be found here ...
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/

One just has to manually enter and run the install command for Stubby installer. After that the menu entry appears in amtm.