What's new

[Preview] 380.57 alpha test builds for all models

  • 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.
My understanding is the at least the CPU will be the 1ghz CPU found in the 68P's. Not sure about the radios.

Alpha 4 working great on my 1ghz 68U Rev B1.
 
Alpha4 is behaving really bad herevwith 68u. Went back to alpha3. Maybe a factory default will work, power cycles did not do a proper job. Behaviour was locking up of interface access and wireless locking up at both 2.4 and 5 GHz band.
 
Try a factory default, new SDK inside.
 
My understanding is the at least the CPU will be the 1ghz CPU found in the 68P's. Not sure about the radios.

No, it will still be a bcm4708 (the RT-AC68P has a bcm4709), but a new revision of the chip, and a new clock rate. There are other internal changes since it requires a newer SDK, but only Broadcom would know what else they changed.

Might also be other hardware-level changes (for instance the LED button is now a toggle instead of a switch), but I don't know what they are.
 
The RT-AC66U breakage is caused by a compatibility issue between the 378 closed source binary blobs and the 380 source code. Some 378-based models still work through pure luck. The root cause is an enumerated list of model IDs in shared/shared.h changed between 378 and 380, causing model IDs to be off by one. inside those precompiled components that used a different enumerated list of models.

At this point, it probably means that 380.57 will be limited to 380-native models, until Asus updates those other models to the 380 codebase, or provides otherwise compatible binary blobs for those missing models.

This is the consequence of having so much code moved into closed source component. The same issue happened with the RT-N66U and 378.56. Expect them to keep happening in the future, it's totally outside of my control. The only way to avoid it would be to have full access to the source code - not something I expect to happen.

Thanks, FCC.
 
Loaded alpha4 on 87U directly from latest alpha3 without a factory default afterwards just to see. All looks good so far after 4hrs on Lan and both wireless.

Reading previous posts I check 5GHzs preamble via telnet commands cause it still not an option on professional. It was set to long. used commands to set to short.

Only thing I have noticed is the "Site Survey" is not generating an output. I don't use it much, and have seen it behave flaky but will end up listing surrounding wifi networks. I have not been able to get it to generate a report since upgrading to alpha4. No biggie for me, just stating an observation.
 
Upgraded my AC-3100 to A-4 this afternoon and no issues to report working excellent. :) :D
 
Last edited by a moderator:
Kal-El,

Can you point me to where you get the AC3100 Alpha 4 version from or did you self compile? All I could find was Alpha 3.

Thanks!
 
"No, it will still be a bcm4708 (the RT-AC68P has a bcm4709)"

Mine is the 4709.

Alpha 4 working great. Very snappy. Wireless throughput seems faster. Had a few lags with Alpha 3. None so far with 4.
 
Last edited:
RT-AC68U B1 (EUROPE) = RT-AC68P (USA)

Both use BCM4709 at 1GHZ clock speed and same bootloader. (1.0.2.5)
 
Last edited:
Try a factory default, new SDK inside.
New SDK leads to new driver versions:
Command: grep -i Broadcom /tmp/syslog.log* | more

Result RT-AC68U_380.57_alpha3-g50ed89c:
/tmp/syslog.log-1:Aug 1 02:00:16 kernel: eth0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 6.37.14.105 (r485445)
/tmp/syslog.log-1:Aug 1 02:00:16 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.105 (r485445)
/tmp/syslog.log-1:Aug 1 02:00:16 kernel: eth2: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.105 (r485445)

Result RT-AC68U_380.57_alpha4-gf1feccb:
/tmp/syslog.log:Aug 1 02:00:17 kernel: eth0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 6.37.14.126 (r561982)
/tmp/syslog.log:Aug 1 02:00:17 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.126 (r561982)
/tmp/syslog.log:Aug 1 02:00:17 kernel: eth2: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.126 (r561982)
 
Thx Merlin for the investigations on the ac66 incompatility with 380 branch.

Envoyé de mon Nexus 6 en utilisant Tapatalk
 
New SDK leads to new driver versions:

Command: grep -i Broadcom /tmp/syslog.log* | more

Result RT-AC68U_380.57_alpha3-g50ed89c:
/tmp/syslog.log-1:Aug 1 02:00:16 kernel: eth0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 6.37.14.105 (r485445)
/tmp/syslog.log-1:Aug 1 02:00:16 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.105 (r485445)
/tmp/syslog.log-1:Aug 1 02:00:16 kernel: eth2: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.105 (r485445)

Any improvement on 5GHz throughput with the new driver?
 
Status
Not open for further replies.

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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