What's new

[Preview] Asuswrt-Merlin 384.4 test builds

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

Status
Not open for further replies.

RMerlin

Asuswrt-Merlin dev
As usual,, I will occasionally upload pre-beta test builds to the https://asuswrt.lostrealm.ca/test-builds folder.

These are early test builds, which have received very limited testing. They are still work-in-progress, so things can be broken, and things will change before reaching the beta stage.

No support is provided for these test builds, and no ETA either.
 
As usual,, I will occasionally upload pre-beta test builds to the https://asuswrt.lostrealm.ca/test-builds folder.

These are early test builds, which have received very limited testing. They are still work-in-progress, so things can be broken, and things will change before reaching the beta stage.

No support is provided for these test builds, and no ETA either.
I notice the AC3100 is not among the new 384.4 alpha builds. Will you be posting an alpha for it as well?
 
I notice the AC3100 is not among the new 384.4 alpha builds. Will you be posting an alpha for it as well?

Eventually, I just didn't compile it in that batch because I didn't need to test it for what I was working on.
 
This fixes the wireless link rate issue that was present in previous builds, so far so good on my AC86U.

One bug I have noticed since attaching a 2TB WD Elements HDD (ext4 formatted) yesterday to the router is that SMB during large transfers (100GB+) will occasionally cause the client to disconnect and refuse said client to make a reconnection of any kind until the wireless service is restarted or full reboot. This happened twice in the last 24 hours while I was transferring about 500GB of data once on the previous and once on the current release.

For reference I also have a swap file on a flashdrive in the USB 2 slot.
 
I just installed Alpha 1 on my RT-AC68U and noticed that the log messages for QoS starting up and then the repeating "Unable to send packet on real......" messages were still in the log the same as for 384.3

I have then simply applied the existing settings unchanged on the log page, received 2 busybox related messages, and at least for now the "Unable to send packet" messages seem to have stopped. Could it be something to do with how the log page is getting initialised?
upload_2018-2-16_14-40-19.png
 
This fixes the wireless link rate issue that was present in previous builds, so far so good on my AC86U.

That was fixed in 384.3 as well, where I backported these networkmap changes. The fix was to have model-specific networkmap binaries.
 
Getting some errors in log after upgrade.
Feb 16 15:49:33 kernel: net_ratelimit: 705 callbacks suppressed
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:49:33 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:49:51 kernel: net_ratelimit: 1308 callbacks suppressed
Feb 16 15:49:51 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:49:51 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:50:05 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:50:05 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:50:19 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:50:19 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:50:19 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:50:20 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:50:20 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:50:20 kernel: protocol 0800 is buggy, dev eth0
Feb 16 15:50:20 kernel: protocol 0800 is buggy, dev br0
Feb 16 15:50:20 kernel: protocol 0800 is buggy, dev eth0
Also QOS setting was changed from gaming to custom after upgrade.

Edit: modell ac86u
 
Last edited:
Ive noticed a similar disconnection effect after applying changes that i believe cause the wireless driver to restart in every build merlin or official. For me what happens is i apply the change and service restarts and drops wifi connection obviously but... it never reappear as a network to connect to in windiws10 untill i manually toggle airplane mode on my wireless ae6000 usb wifi. Ive always assumed it was just my wifi not liking how the router was performing that disconnect and dudnt worry about it but is annoying


This fixes the wireless link rate issue that was present in previous builds, so far so good on my AC86U.

One bug I have noticed since attaching a 2TB WD Elements HDD (ext4 formatted) yesterday to the router is that SMB during large transfers (100GB+) will occasionally cause the client to disconnect and refuse said client to make a reconnection of any kind until the wireless service is restarted or full reboot. This happened twice in the last 24 hours while I was transferring about 500GB of data once on the previous and once on the current release.

For reference I also have a swap file on a flashdrive in the USB 2 slot.
 
Getting some errors in log after upgrade.

Also QOS setting was changed from gaming to custom after upgrade.

It might be worth trying to re-save the log settings without changes - it calmed my log down. I suspect we might be getting debug messages slipping through.
 
I second the thanks for an AC87U build of 384, although not brave enough to try an alpha build!

I was concerned at all the security fixes in Asus's latest 382 build not making it to Merlin on the AC87U. Silly question though is there a source code 384 for this router then, or is one not specially needed as the latest public build is on the 382 code.

Also on a side note, looking around these forums I didn't realise there were supposed to be 5 GHz issues with this router, I only use 2.4 GHz for a single legacy device, everything else is on 5 GHz and they are all Apple products - currently 3xApple TV 4's, 3x iPad mini 2's & 2x iPhone X's currently with no WiFi issues that I know of, been running this router for 2 years with no issues. Odd one that and I stream 600+ GB a month of Netflix on the Apple TV's, although thinking on that occasionally Netflix has a glitch where content wont play - maybe that is a router glitch.
 
Last edited:
Silly question though is there a source code 384 for this router then, or is one not specially needed as the latest public build is on the 382 code.

The 382_50010 binary blobs are compatible (so far, need more testing) with the 384_20379 GPL code.
 
This boring and annoying message is still there when both radios are not activated

:unable to send packet on real device for eth2: No buffer space available
 
Installed it on my AC56u. All is working fine. No errors in systemlog.
I've been watching 4 hours netflix + youtube, used Wifi with my smartphone and tested OpenVPN Server.
 
Last edited:
Currently stable. At the WLAN website (2,4+5 GHz), the channel is not displayed.
 

Attachments

  • wlan.JPG
    wlan.JPG
    29.9 KB · Views: 750
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top