Beta [DSL-AC68U] Asuswrt-Merlin 386.x Alphas for DSL-AC68U are now available

[GNUton]

Hi,

did not improve. the problem continues.

It happens when I open the intranet. but the guest is not asked to access the intranet.

Please write down the way to reproduce this, since it works for me.

 

[Osman Elitok]

Please write down the way to reproduce this, since it works for me.

I'm sorry I didn't understand

 

[GNUton]

No worries. I think I got the problem and I have updated the ticket.
The bug is there, but slighly different now. cheers.

 

[Osman Elitok]

No worries. I think I got the problem and I have updated the ticket.
The bug is there, but slighly different now. cheers.

Thank you.

 

[GNUton]

Hi there,
A new alpha build is available. The main attempt of this build is to fix the NVRAM running low notification issue.
The problem there was in the miscalculation of the used nvram.
Just to be clear:
- If you use 386 firmware pre-alpha 8 you can ignore that warning.
- If you are using 384 firmware, or firmware >= 386.00_0-gnuton0_alpha8 that warning is real.

Explanation:
On 384 based firmware all nvram vars are stored on the device nvram which is fixed to 64KB.
On the 386 based firmware, the nvram variables are partially stored on the device nvram and some others are in /jffs/nvram directory.
Nvram notifications are now triggered only when the device nvram is really running low.
Beside this there is already a JFFS check for catching JFFS free disk running low, so you will get notifications for that too.

As for the old trick of unsetting vars, it is still good and valid in case you are really need it.
Please report if you see any anomaly or if it works for you.
Thanks.

 

[r0bbieNZ]

Thanks @GNUton Seemed to do the trick - no warnings and usage looks normal !!!

Hi there,
A new alpha build is available. The main attempt of this build is to fix the NVRAM running low notification issue.
The problem there was in the miscalculation of the used nvram.
Just to be clear:
- If you use 386 firmware pre-alpha 8 you can ignore that warning.
- If you are using 384 firmware, or firmware >= 386.00_0-gnuton0_alpha8 that warning is real.

Explanation:
On 384 based firmware all nvram vars are stored on the device nvram which is fixed to 64KB.
On the 386 based firmware, the nvram variables are partially stored on the device nvram and some others are in /jffs/nvram directory.
Nvram notifications are now triggered only when the device nvram is really running low.
Beside this there is already a JFFS check for catching JFFS free disk running low, so you will get notifications for that too.

As for the old trick of unsetting vars, it is still good and valid in case you are really need it.
Please report if you see any anomaly or if it works for you.
Thanks.

 

[Cnckmk]

Hi,

how can I increase wifi signal coverage ? does this firmware help me max it up ?

 

[inakaya]

Hi,

how can I increase wifi signal coverage ? does this firmware help me max it up ?

Search is your friend but to save you the trouble try here

 

[Zendilar]

Hi there,
A new alpha build is available. The main attempt of this build is to fix the NVRAM running low notification issue.
The problem there was in the miscalculation of the used nvram.
Just to be clear:
- If you use 386 firmware pre-alpha 8 you can ignore that warning.
- If you are using 384 firmware, or firmware >= 386.00_0-gnuton0_alpha8 that warning is real.

Explanation:
On 384 based firmware all nvram vars are stored on the device nvram which is fixed to 64KB.
On the 386 based firmware, the nvram variables are partially stored on the device nvram and some others are in /jffs/nvram directory.
Nvram notifications are now triggered only when the device nvram is really running low.
Beside this there is already a JFFS check for catching JFFS free disk running low, so you will get notifications for that too.

As for the old trick of unsetting vars, it is still good and valid in case you are really need it.
Please report if you see any anomaly or if it works for you.
Thanks.

If it is limited to hardware that is an other story, but if it is fixed by the firmware then maybe it is possible for you to increase it a litle, like 128KB if that is possible.
I am saying because a lot of people are referring to low NVRAM including my self and every time I reboot the devise I have to do the old SSH trick

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

 

[GNUton]

NV

If it is limited to hardware that is an other story, but if it is fixed by the firmware then maybe it is possible for you to increase it a litle, like 128KB if that is possible.
I am saying because a lot of people are referring to low NVRAM including my self and every time I reboot the devise I have to do the old SSH trick

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

Hi!
I cannot increase the NVRAM size only from firmware. It must be increased in the bootloader.
Beside that I guess that nor us nor asus can do that since there is a limitation in the hardware.
Infact ASUS from 386 provides a workaround for it by storing part of the vars in /jffs/nvram.
That's enabled in my builds too.

Honestly we should not be worried too much about nvram size now. And in case that would not be enough I do have an idea on how to work around that.
So do not be worried about this!

 

[Bluemosh]

Hi guys, hows the stability of the newest alpha going? I love the firmware and have been running 384.17 for ages now and it's been great! Thanks for all your hard work! My situation is that I manage my home network for my family, who all use a lot of tech and the network performance is crucial to them! We live on quite a large property and I've set up 2 additional routers using AiMesh which works pretty well, however, I'm eager to try this new version.

What I'm wondering is: Is the latest alpha stable enough for me to flash it and get it set up before I leave town in a weeks time, so that everyone can benefit from the new features. With the plan that I can update it remotely when the stable release is hopefully finished? (Don't worry I do it safely remoting into a PC wired in on the network to do the actual flashing)
Ideally, a stable version for me would be one that survives until a weekly reboot without requiring anything more than a power cycle if something does break (the limits of my father's networking troubleshooting)

The current setup I have is:

• Flex QoS with a few custom rules that I'll hopefully be able to backup and restore to the new firmware.
• OpenVPN server allowing me to remote in and check the network and perform any updates via amtm using SSH.
• AiMesh setup utilising two other 68U routers using wired backhaul.

On a side note whilst I'm here, should I reset and run the 68U nodes on the stock 386 version or use merlins? Any advice on that would be greatly appreciated!

Thanks in advance for any help! And thank you again to GNUton for your hard work keeping us DSL guys up to date with the cool kids!

 

[Osman Elitok]

Hello there,

I have been using it with 4gb usb stick (JFFS) since alpha8 came out, it works very stable.

I also have +2 RT-AC68U Aimesh router and it works without any problem.

I use GNUton software on the DSL-AC68 one, others have asus software. I guess Merlin software didn't support Aimesh.

Thanks GNUton.

 

[GNUton]

Hi guys, hows the stability of the newest alpha going? I love the firmware and have been running 384.17 for ages now and it's been great! Thanks for all your hard work! My situation is that I manage my home network for my family, who all use a lot of tech and the network performance is crucial to them! We live on quite a large property and I've set up 2 additional routers using AiMesh which works pretty well, however, I'm eager to try this new version.

What I'm wondering is: Is the latest alpha stable enough for me to flash it and get it set up before I leave town in a weeks time, so that everyone can benefit from the new features. With the plan that I can update it remotely when the stable release is hopefully finished? (Don't worry I do it safely remoting into a PC wired in on the network to do the actual flashing)
Ideally, a stable version for me would be one that survives until a weekly reboot without requiring anything more than a power cycle if something does break (the limits of my father's networking troubleshooting)

The current setup I have is:

• Flex QoS with a few custom rules that I'll hopefully be able to backup and restore to the new firmware.
• OpenVPN server allowing me to remote in and check the network and perform any updates via amtm using SSH.
• AiMesh setup utilising two other 68U routers using wired backhaul.

On a side note whilst I'm here, should I reset and run the 68U nodes on the stock 386 version or use merlins? Any advice on that would be greatly appreciated!

Thanks in advance for any help! And thank you again to GNUton for your hard work keeping us DSL guys up to date with the cool kids!

Hi,
The current status is: it's kind of beta more than alpha. Safe to use if you are fine with the glitches it may have. IIRC OpenVPN is still having some fixes from upstream merlin code;
Bottom line, if you have time you can test it and see if it fits your needs. The safer approach is of course sticking to 384 a little bit longer and wait for the release that will come after the official merlin one.

I will release the beta as soon as the new Asus GPL code gets merged into merlin codebase

 

[Osman Elitok]

alpha 9 is very nice and much more stable thanks @GNUton

 

[GNUton]

Hi,
Nice somebody has noticed it before me announcing it.
The new alpha9 is based on the latest Asus GPL as the mainstream Merlin Asuswrt.

A lot of issues found in previous alpha and related to prebuilds should now be fixed.
Enjoy!

 

[BoostOver]

A lot of issues found in previous alpha and related to prebuilds should now be fixed.
Enjoy!

Grande GNUton.
Appena riesco ti faccio la donazione.
Peccato per la mancanza delle opzioni in QoS tradizionale nell'ultima alpha9.

 

[Osman Elitok]

Hi,
Nice somebody has noticed it before me announcing it.
The new alpha9 is based on the latest Asus GPL as the mainstream Merlin Asuswrt.

A lot of issues found in previous alpha and related to prebuilds should now be fixed.
Enjoy!

Hello GNUton,

I've spotted some issues in Alpha 9 and want to share.

- When the guest network is active, there is no internet access without opening the intranet.

- Game and Open NAT options (port opening, QOS) none work. I tried it for CS GO.

- Speed test Upload problem occurred in browsers.

For example,

Edge (Chromium) Upload 1mbps
Google Chrome Upload 3 mbps
Internet Explorer Upload 6 mbps
Windows Speed Test App Upload 7 mbps

I've done these tests over and over. All the same 70mbps download is okay but there is a problem with the upload.

This issue was resolved when I switched to Alpha 8. I'm using alpha 8 now.

Greetings.

 

[Bluemosh]

I also spotted the new alpha release after recieving an email from github, and flashed it to give it a go. Aside from a couple strange AiMesh hiccups straight after the flash (resolved by a whole system reboot) and the webgui initially being unresponsive (which somehow self-resolved, I suspect a background task taking up resources), its now been running absolutely flawlessly and performance has been fine, great work!

- Speed test Upload problem occurred in browsers.

For example,

Edge (Chromium) Upload 1mbps
Google Chrome Upload 3 mbps
Internet Explorer Upload 6 mbps
Windows Speed Test App Upload 7 mbps

I've done these tests over and over. All the same 70mbps download is okay but there is a problem with the upload.

This issue was resolved when I switched to Alpha 8. I'm using alpha 8 now.

In relation to this, I cannot replicate this on my end, with alpha 9 the upload has worked fine and follows my QoS settings as expected. (attached, my connection is 55Mbps down/12Mbps up)
Although, I havent properly used the new game functionality other than enabling the game device prioritization, without selecting any devices my pings in games are stable as can be and I have not experienced any network lag at all.

Maybe I'm just lucky and YMMV, however, it also might point to an issue with your install, I did a full reset using the WPS button after flashing and reconfigured everything, including using SSH to reset my AiMesh nodes using "nvram erase" followed by "reboot" to rejoin them to my network.

Maybe worth trying a full reset after flashing and seeing if you can still reporoduce the issues, so we can actually give GNUton a good base to work off!

 

[GNUton]

Hello GNUton,

I've spotted some issues in Alpha 9 and want to share.

- When the guest network is active, there is no internet access without opening the intranet.

- Game and Open NAT options (port opening, QOS) none work. I tried it for CS GO.

- Speed test Upload problem occurred in browsers.

For example,

Edge (Chromium) Upload 1mbps
Google Chrome Upload 3 mbps
Internet Explorer Upload 6 mbps
Windows Speed Test App Upload 7 mbps

I've done these tests over and over. All the same 70mbps download is okay but there is a problem with the upload.

This issue was resolved when I switched to Alpha 8. I'm using alpha 8 now.

Greetings.

Hi and thanks for testing it out.
I have been running the alpha9 for a few days now and I ahve not noticed any slowness in the upload speed,
DSL driver is the same as in alpha8. Wireless driver is newer.
Please double check if see any difference in speed when using cable or wireless.

Beside this, the speeds of different browsers on the same OS should be the raughly the same.

I will check the rest.

Thanks

 

[Osman Elitok]

Hi and thanks for testing it out.
I have been running the alpha9 for a few days now and I ahve not noticed any slowness in the upload speed,
DSL driver is the same as in alpha8. Wireless driver is newer.
Please double check if see any difference in speed when using cable or wireless.

Beside this, the speeds of different browsers on the same OS should be the raughly the same.

I will check the rest.

Thanks

I'm sorry I haven't said this before. No problem when connected wirelessly. I have a problem when I connect wired. It had been on official asus software before. They retracted the software.

Thanks