Beta [Fork] Asuswrt-Merlin 374 LTS development 47D9 - RT-AC68U V3 support

[john9527]

LATEST RELEASE: Update-47D9
1 February 2021
Merlin fork 374.43_47D9j9527
============================

Update-47D9 Highlights

• Support for RT-AC68U V3 routers. Includes updated wireless drivers that are used for all RT-AC68U hardware levels
• Update NFS daemon for ARM routers (AC56 and AC68). MIPS based routers’ kernel is not compatible with the update and continues with the previous level.
• Base commit level equivalent to 46E9 release, including DNSpooq update.

Testing Needed

• It is my intent to migrate to the new wireless drivers for all future AC68U builds, so testing on non-V3 hardware is encouraged. In my testing, there is no difference with the new drivers on the older hardware (they may actually perform a bit better).
• Testing on AC56U. There are some common ARM components updated as part of the AC68U V3 support. I don’t expect there to be a problem, but would like confirmation from user testing prior to release.

Special thanks to @SomeWhereOverTheRainBow , @galbert for being the first to try the new support and to @ColinTaylor for helping to verify the older hardware.


Full ChangeLog: Changelog.txt in the download directory

Downloads
Latest development release: https://1drv.ms/f/s!Ainhp1nBLzMJiF2l3WjM46lSmxrH

SHA256
(Default Build - All supported routers)
ccfa85352a82426551ffa5111d7384ba70140a0d80df1f39677db515c5d0d7e5 RT-N16_374.43_47D9j9527.trx
8eb6bc02e6ebf9b578ffcda0cf03b76c7bcb0a4f80b7b95ded89f664856db1ae RT-AC66U_374.43_47D9j9527.trx
1b04866511a69d0111991ef1cdfadf253b4911aec18dad2f01d534bb891679ec RT-N66U_374.43_47D9j9527.trx
ae2d9bb9cc23a65144801599c5961fb1a84976764add5ed0649f244c00fc8ccd RT-AC68U_374.43_47D9j9527.trx
eebe9b4a3f35caf88ce6a165646dcf0959caa376aed5c17370821aace588d300 RT-AC56U_374.43_47D9j9527.trx

 

[john9527]

Reserved

 

[jrmwvu04]

Still kicking over here.. been using 47D3 on 1900P for a few days, nothing interesting to report. The only thing that has changed much lately is that I'm no longer using QoS as my connection speed has eclipsed what QoS can handle on the downlink

 

[john9527]

Refreshed the Beta to 47D7, including DNSPOOQ security updates. The initial dnsmasq release problems appear to be fixed with the 2.84test3 release.
Builds are now available for all supported routers.

 

[ualdrivr]

Hi @john9527 , I've been running your fork firmware with great success on my 68U for many years. I always update the firmware when you put a new version out. Thank you for all you do. I want to get another ASUS router for the house. I was looking at the 88U, 86U or the 5300 models. Haven't decided yet. The idea is to use the AiMesh feature and have my current 68U as an extension for my Network. Will it work with your fork or do I have to revert to ASUS' firmware or Merlin's and if yes how should I do it? Does it need a whole factory reset? Please help. Thanks

 

[L&LD]

Your best bet would be to flash to the firmware (Asus or RMerlin) and codebase of the main router.

To flashback to RMerlin firmware from @john9527's fork, follow the steps below using Asus' Rescue Mode.

Asus Rescue Mode

 

[john9527]

I was looking at the 88U, 86U or the 5300 models. Haven't decided yet. The idea is to use the AiMesh feature and have my current 68U as an extension for my Network. Will it work with your fork or do I have to revert to ASUS' firmware or Merlin's and if yes how should I do it? Does it need a whole factory reset? Please help. Thanks

Time marches on.... My fork doesn't support any of the models you are looking at, It also doesn't support AiMesh. So you'll need to move to either the ASUS OEM or Merlin firmware for both your new router and existing AC68U.

You can upgrade to either of those firmware's on the AC68 from my fork gui. Then you'll need to factory reset and configure the new firmware from scratch. Don't try and use any saved configs from the fork.

Good luck with your new network!

 

[john9527]

Development Beta refreshed to 47D9. Details in first post.

 

[ColinTaylor]

@john9527 The NFS problem is now present in this version as well. All the processes seem to be running OK without any errors. From the Windows 10 command prompt I can run rpcinfo and showmount and they report all the correct information. I can even run mount and it successfully mounts and maps a drive. The only thing that isn't working is the visibility in Windows Explorer > Network. I'm wondering whether this is a deliberate security enhancement similar to the way network browsing was removed from SMBv2.

EDIT: Was the router's NFS service somehow integrated with Samba in the previous version? The reason I ask is because I remember seeing in Windows Explorer the "Discovery Method" listed as NetBIOS.

 

[john9527]

The NFS problem is now present in this version as well.

Hmm...works fine for me...both legacy and normal modes.

 

[john9527]

Was the router's NFS service somehow integrated with Samba in the previous version? The reason I ask is because I remember seeing in Windows Explorer the "Discovery Method" listed as NetBIOS.

No direct connection with Samba that I can see. Yes, the Discovery Method for the NFS share is listed as NetBios. I don't have SMB 1.0 enabled on the Win10 box.
Maybe it needs the Master Browser part of Samba. I have it set for the router.

 

[ColinTaylor]

No connection with Samba that I can see. Yes, the Discovery Method for the NFS share is listed as NetBios. I don't have SMB 1.0 enabled on the Win10 box.
Maybe it needs the Master Browser. I have it set for the router.

View attachment 30207

Same here. I only had SMBv2 enabled and my master browser is on a Linux server. I tried changing the router to SMBv1+v2 but it didn't help. Just restarted the master browser but no change.

 

[john9527]

I'm at a loss....I'll try playing with it to see if I can get it to fail. My Win10 install is very 'bare bones'. My daily use boxes are all Linux. I really only keep a Win10 box around for software not available on Linux, like my tax prep software.

 

[ualdrivr]

Time marches on.... My fork doesn't support any of the models you are looking at, It also doesn't support AiMesh. So you'll need to move to either the ASUS OEM or Merlin firmware for both your new router and existing AC68U.

You can upgrade to either of those firmware's on the AC68 from my fork gui. Then you'll need to factory reset and configure the new firmware from scratch. Don't try and use any saved configs from the fork.

Good luck with your new network!

Thank you @john9527 That's what I figured. So just a straight upgrade to Merlin and a factory reset afterwards. Got it. Thanks again.

 

[ColinTaylor]

I'm at a loss....I'll try playing with it to see if I can get it to fail. My Win10 install is very 'bare bones'. My daily use boxes are all Linux. I really only keep a Win10 box around for software not available on Linux, like my tax prep software.

Well I've spent all day experimenting with this on two separate Win10Pro computers (with different builds) and I'm as confused as ever. Switching back and forth between 47D7 and 47D9 the only consistent behaviour is 47D7 which always works. 47D9 sometimes works but I suspect that part of the problem is that Windows Explorer remembers the NFS share until Windows is rebooted. So Windows needs to be rebooted after switching firmware versions. But even this behaviour doesn't seem to be consistent. Both the Win10Pro machines are only used for testing so are almost in a vanilla state with no additional software installed.

 

[L&LD]

@ColinTaylor, you may want to test the Windows PCs by holding down the Shift key when hitting the Shutdown command and leaving them off for a minute before powering them up again. That should clear anything Windows 10 is 'remembering'.

Normally, shutdown, shutdown with the Shift key held down, and a reboot is putting Windows in different states. With the Shift key method being the 'cleanest'. I would also disable hibernate, the page file if you have enough RAM (at least just to test this with even), and the restore points in Windows too. Everything is cached, somewhere.

 

[ColinTaylor]

UPDATE: Long story short; the "trick" to getting Explorer to detect NFS with this build is to enable NFS V2 support and then reboot or shift-shutdown (not a normal shutdown) Windows.

---

Thanks for the suggestion @L&LD. I was aware of the "fast boot" problem when I was testing and thought I had that covered but you inspired me to go back and check it again.

I think I now understand that there's a combination of two things:

1. Windows Explorer only adds or removes the NFS shares the very first time it runs after a cold boot. So flashing different firmware versions or turning NFS on or off in the router has no effect until the PC is cold booted.

2. The PC must be cold booted, so that means doing a "Restart" or as @L&LD said using the Shift-Shutdown method.

So that said, whatever this "one time discovery" thing is that Explorer is doing isn't working with the new firmware release. That's not to say that the NFS client isn't working because as mentioned above showmount and mount work from the command prompt in any scenario.

@john9527 Can you check your Windows 10 PC again after doing a Reboot rather than a Shutdown please.

 

[Gar]

47D9 running fine on my simple system with 5 clients. Thanks again.

Edit: Still running fine, no issues.

 

[Max-H]

Flashed this morning 374.43_47D9j9527 on my RT-AC68U Rev. A1. Update process smooth as always. One USB connected to a WD Passport HD, second to a Epson printer. I only had to unplug/plug the WD harddrive. After flashing the firmware the drive was unmounted.
Overall fast wifi connection speeds on different laptops (+/- 400/40Mbps down/up), (510/40 wired desktop). Thx again for you effort.

 

[john9527]

Flashed this morning 374.43_47D9j9527 on my RT-AC68U Rev. A1

Thanks for the early AC68U datapoint....

Still looking for some feedback on AC56