What's new

[Preview] Asuswrt-Merlin 384.3 pre-release 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.
I flashed it on my ac68u...there is a problem on enable/disable guest network !!If I enable a guest network it will be visible only after a reboot of the router and if I remove a guest network it continue to be visible on all wifi devices.Please fix it.
 
Last edited:
@RMerlin

Think you might need to revert your fix for QoS upload stats info not working on the 86U for the new GPL merge.

Same here: installed alpha 1 on my RT-AC86U and the upload chart pie on QoS statistics no longer works. Still is present the same bug on renaming the client after the 30ish entry, but I know Merlin this is beyond your control
 
Yes, I read that when you mentioned it. I do see the codel patch being applied. I tried with and without @FreshJR QoS script (QoS is on, Adaptive, manual bandwith settings, fq_codel, 20/200) and I see it starts and starts adjusting classes after about 3 minutes, but graphs are still not showing up. Restarted QoS multiple times (toggled off and on), rebooted, but to no avail.

tc shows no output either:

Code:
ASUSWRT-Merlin RT-AC68U 384.3-alpha1-gf682bb3 Thu Jan 18 05:43:01 UTC 2018
marco@RT-AC68U:/tmp/home/root# tc filter show dev eth0
marco@RT-AC68U:/tmp/home/root# tc filter show dev br0
marco@RT-AC68U:/tmp/home/root#

so I don't know what else I can do?
These are the exact symptoms I had with a test build for the RT-AC56U using the binary blobs of the RT-AC68U. Your report seems to indicate that it is not a matter of the 68U blobs being compatible with the 56U but possibly those blobs being incompatible with the newer GPL code. In any case lets wait for @RMerlin 's input.

EDIT: On the other hand, the AC68U does have newer binaries for the 384 release as seen here so I am not sure what is going wrong. Could it be something that was merged wrong? Unknown for now.
 
Last edited:
I noticed that the Network Map shows all the connections as 'Wired' and does not properly categorize the wireless clients.

my AC88u shows correct.
 
my AC3200 shows correctly conn categories in client list and the QOS stat pies too ...
 
These are the exact symptoms I had with a test build for the RT-AC56U using the binary blobs of the RT-AC68U. Your report seems to indicate that it is not a matter of the 68U blobs being compatible with the 56U but possibly those blobs being incompatible with the newer GPL code. In any case lets wait for @RMerlin 's input.

EDIT: On the other hand, the AC68U does have newer binaries for the 384 release as seen here so I am not sure what is going wrong. Could it be something that was merged wrong? Unknown for now.

I really don't know. As said, I do see the codel patch being applied and @FreshJR's script getting started. Looking at syslog, it does take 3 minutes before the script actually changes the categories, which makes me thing it works. Yet the graphs are missing at the QoS statistics page, so I am not sure if it's actually working...

Code:
Jan 19 10:05:07 RT-AC68U qos:  Applying codel patch
..
Jan 19 10:06:50 RT-AC68U rc_service:  httpd 289:notify_rc restart_qos;restart_firewall
..
Jan 19 10:07:49 RT-AC68U marco:  Adaptive QOS: Modification Script Started
..
Jan 19 10:10:49 RT-AC68U marco:  Adaptive QOS: Changing container for Unidentified Traffic & Applying Custom Rules
Jan 19 10:10:50 RT-AC68U marco:  Adaptive QOS: Changing minimum alloted bandwidth per QOS category to user defined percentages
 
I really don't know. As said, I do see the codel patch being applied and @FreshJR's script getting started. Looking at syslog, it does take 3 minutes before the script actually changes the categories, which makes me thing it works. Yet the graphs are missing at the QoS statistics page, so I am not sure if it's actually working...

Code:
Jan 19 10:05:07 RT-AC68U qos:  Applying codel patch
..
Jan 19 10:06:50 RT-AC68U rc_service:  httpd 289:notify_rc restart_qos;restart_firewall
..
Jan 19 10:07:49 RT-AC68U marco:  Adaptive QOS: Modification Script Started
..
Jan 19 10:10:49 RT-AC68U marco:  Adaptive QOS: Changing container for Unidentified Traffic & Applying Custom Rules
Jan 19 10:10:50 RT-AC68U marco:  Adaptive QOS: Changing minimum alloted bandwidth per QOS category to user defined percentages
Since you have the RT-AC68U, which uses the same SDK as my AC56U, if you do not see the pie charts then Adaptive QoS is NOT working regardless of what you see in the logs. FreshJR's script will always display that message as it does not find the default tc class (1:17), in your case it will never find it as it isn't even created in the first place! Also in your previous message you gave some command line output which is even more specific, there is no QoS whatsoever.
 
I flashed it on my ac68u...there is a problem on enable/disable guest network !!If I enable a guest network it will be visible only after a reboot of the router and if I remove a guest network it continue to be visible on all wifi devices.Please fix it.

Did you restart the RT-AC68U after flashing? I also use the guest network on my RT-AC68U and it just works well here.
 
Running 384.3 alpha 1 on my RT-AC86U. No issues to report yet.

(probably setting up Entware, AB-Solution, pixelserv, Skynet & Unbound this weekend)
 
On my RT-AC86U, I've a lot of this:

Code:
gpnrd[15693]: gpn_sendto() failed in send_data: Bad file descriptor

Even an unexpected restart
 
Last edited:
Also in your previous message you gave some command line output which is even more specific, there is no QoS whatsoever.

That's what I was afraid of. Thanks for your confirmation. Apparently not all issues with QoS have been solved in the 384 branch, unfortunately.
 
After upgrading my AC88U to 384.3 from 382.1 I am seeing a burst of these messages every 5 mins:

Jan 19 06:19:16 kernel: net_ratelimit: 1375 callbacks suppressed
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow

After loading the firmware, I did a factory reset (held reset button for 5 seconds) and then used John9527 restore nvram utility (R26.2).

I did a search and see that this has come up before. I might try a second factory reset. Before I do, anyone else seeing this?
 
After upgrading my AC88U to 384.3 from 382.1 I am seeing a burst of these messages every 5 mins:

Jan 19 06:19:16 kernel: net_ratelimit: 1375 callbacks suppressed
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow
Jan 19 06:19:16 kernel: TCP: time wait bucket table overflow

After loading the firmware, I did a factory reset (held reset button for 5 seconds) and then used John9527 restore nvram utility (R26.2).

I did a search and see that this has come up before. I might try a second factory reset. Before I do, anyone else seeing this?
I believe it's being discussed, not to use restore nvram utility for now, especially restore from pre-384 fw
 
I believe it's being discussed, not to use restore nvram utility for now, especially restore from pre-384 fw
Thanks. I am going to factory reset and just try to restore my dhcp_staticlist.
I can do the rest manually (sadly)...
 
I discovered an issue in the 384.3 Alpha 1 build when trying to use a second RT-AC68U in repeater mode in order to extend the wifi coverage without using AiMesh. I upgraded both the primary router (also an RT-AC68U) and the repeater to 384.3 Alpha 1, and the repeater would no longer connect. I tried moving the repeater to the ASUS 3.0.0.4.384.10007 build -- still no luck. I downgraded the repeater to to Merlin 382.2 Beta 3 (leaving the primary router at 384.3 Alpha 1), and I was able to re-establish connectivity to the repeater.

It appears that the 384 builds allow you to change LAN settings (i.e., away from the standard 192.168.1.x network) for the repeater, but they are not actually implemented -- the settings are accepted, but the node returns to 192.168.1.1 following reboot and connection attempt. I am guessing that ASUS has changed the way it handles repeater mode as part of its AiMesh implementation.
 
Thanks. I am going to factory reset and just try to restore my dhcp_staticlist.
I can do the rest manually (sadly)...

Did the factory reset (Initialize in the GUI). I then just did jffs-restore.sh from John's scripts. I then did the dhcp_staticlist nvram restore (from the dhcp sort list).
All the while I had an ssh window watching syslog.log (tail -f /tmp/syslog.log).
Everthing looked good. Did a reboot.
Again, syslog.log looked normal.
The restart also had the side effect of running the Entware scripts since I had restored the /jffs/scripts directory. Again, Entware is running fine.

I even went as far and re-enabled FreshJR's latest script in firewall start.
Did the QoS disable/enable and again syslog.log showed normal activity.

So, it does appear that running John9527 nvram backup/restore causes problems. My configuration is not that complex...
 
Did you restart the RT-AC68U after flashing? I also use the guest network on my RT-AC68U and it just works well here.
I haven't restarted ac68u after flashing,but now when I enable a guest network I need to reboot router to be visible on all wifi devices and when I remove a guest network it will not disappear immeddiatily on alll wifi devices...but I need reboot...what's the problem?Thanks
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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