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.
"Usually the Google dns servers are pretty responsive."

Yep. Never seen a slow down with them as long as DNSSEC is off.

DNSSEC has to impact data flow some how otherwise its not really doing anything.
 
DNSSEC only impacts the initial name resolution. Once that initial resolution is done, the answer is cached by the router, as well as by the client computers. So there shouldn't be any noticeable impact, unless you are visiting a website that has tons of outside links, and this is your first visit to it.

This is the same reason why most DNS benchmarks are bogus hocus pocus - you do one single lookup, which resolves in milliseconds, and any subsequent lookups are hitting the local cache.
 
"tons of outside links..."

Whose doesn't any more? So many of them get so bogged down due to that very problem they are frustratingly slow.

I can try it again when chores are done.
 
Using Merlin 380.57_alpha3 since some days now without problems on my RT-N66U. Thanks for this alpha build.
 
Merlin,
RT-AC68U - upon a scheduled reboot (setup for 3:15 AM daily reboot), about once a week I get the following message and cannot reconnect to the router:

Dec 6 03:15:19 kernel: Emergency Sync complete
Dec 6 03:15:19 kernel: SysRq : Emergency Sync

I then must discount power and then it reboots and device are able to connect back to the router.
 
Tried it on my AC87U and about 30-60 mins later I got a 100% CPU (core 2) and it froze up. Couldn't connect wifi clients any more etc.

I just happened to have the admin panel open when the CPU spiked and grabbed a screenshot.

Doesn't really mean much though cos this piece of crap has been crashy since day one. I have to turn off basically every feature just to keep it stable. And by stable I mean getting 4-7 days out of it before it requires a hard reboot.

I'm getting great LAN speeds. Before from my NAS I'd get 60MB/s and now I'm getting 90MB/s. Wireless speeds have gone terribly wrong though, can't seem to get more than 10MB/s & the wifi transmit rate seems to be stuck below 150.
 

Attachments

  • Screen Shot 2015-12-07 at 12.07.50 AM.png
    Screen Shot 2015-12-07 at 12.07.50 AM.png
    297.2 KB · Views: 425
Last edited:
Tried it on my AC87U and about 30-60 mins later I got a 100% CPU (core 2) and it froze up. Couldn't connect wifi clients any more etc.

I just happened to have the admin panel open when the CPU spiked and grabbed a screenshot.

Doesn't really mean much though cos this piece of crap has been crashy since day one. I have to turn off basically every feature just to keep it stable. And by stable I mean getting 4-7 days out of it before it requires a hard reboot.

I'm getting great LAN speeds. Before from my NAS I'd get 60MB/s and now I'm getting 90MB/s. Wireless speeds have gone terribly wrong though, can't seem to get more than 10MB/s & the wifi transmit rate seems to be stuck below 150.


I had mine for 10 months almost now and in beginning it wasnt working they way I wanted but with newer updates and QT FW it is really stable and good now (on both bands 2.4GHz/5GHz). I also running this 380.57_alpha3 commited 24th of November and so far up and running for 11 days now.
 

Attachments

  • ac87u_380.57_alpha3.JPG
    ac87u_380.57_alpha3.JPG
    50.7 KB · Views: 386
It's not. But thiggins has no problem hosting us for free here. He pays the bills, and does the site maintenance. The least I could do is not to make it easy for people to take away whatever financial compensation he gets out of our traffic.

Hardcode a whitelist. ;)
 
RMerlin, I have a question for you about the version numbering scheme. Do you know what Asus's reasoning was to change from the 378. -> 380. version number prefix? Don't see this change very often, and makes me wonder what's behind that change? New wireless driver? New routers supported? Makes me curious...

Thanks!
 
RMerlin, I have a question for you about the version numbering scheme. Do you know what Asus's reasoning was to change from the 378. -> 380. version number prefix? Don't see this change very often, and makes me wonder what's behind that change? New wireless driver? New routers supported? Makes me curious...

Thanks!

I guess that version jump is because of the new router RT-AC88U (RMerlin support it now). From his changelog,

Asuswrt-Merlin Changelog
========================

380.57 (xx-xxx-2015)
- NEW: Merged with 380_858 GPL (from RT-AC88U)
 
RMerlin, I have a question for you about the version numbering scheme. Do you know what Asus's reasoning was to change from the 378. -> 380. version number prefix? Don't see this change very often, and makes me wonder what's behind that change? New wireless driver? New routers supported? Makes me curious...

Thanks!

Software development tends to be planned ahead of time. Most likely they sat down last year, decided what they were going to implement in 378, and completed that plan, and started planning and implementing new features for the 380 codebase, while only doing bugfixes to the 378 codebase - so they currently have two parallel development paths. That's typically a good time to have two separate versions, so you can develop both in parallel.

So far, two of the changes that appeared in 380 are WTFast support, and the start of a webui look revamp (they seem to be replacing those Apple-esque On/Off switches with a new model that's strangely more Android-esque, as a starter).

Note that my own version numbers isn't set in stone however. There is more involved in this specific case with the bump to 378 to 380, related to a new router revision coming to market in early 2016. That new revision won't support older firmwares due to hardware changes, so Asus' plan at this time was for this router to prevent flashing any firmware < 380, to prevent a soft brick. That means that, until I implement the code to support that new model, I might revert back to 378 as the version number. I haven't decided yet.
 
Last edited:
I see a NEW build dated 12/7, Merlin what are the changes from the 11/30 build?

CC

Check those hexadecimal numbers that are part of the filenames - they are the commit numbers at which point in time the builds were compiled.

I was working on improving my build script last night, figured I might just upload the generated files since I had them.

Code:
50ed89c Updated documentation
3329738 igmpproxy: Added support for config customization
4a8644f iptables: Added userspace NOTRACK library (MIPS)
ff2bd4c openssl: Updated to 1.0.2e
58f4a86 nettle: Make sure it gets properly handled by Makefile, for instance on a make clean
a84cace dropbear: Downgraded to 2015.66, every release since then has been broken one way or another
 
Check those hexadecimal numbers that are part of the filenames - they are the commit numbers at which point in time the builds were compiled.

I was working on improving my build script last night, figured I might just upload the generated files since I had them.

Code:
50ed89c Updated documentation
3329738 igmpproxy: Added support for config customization
4a8644f iptables: Added userspace NOTRACK library (MIPS)
ff2bd4c openssl: Updated to 1.0.2e
58f4a86 nettle: Make sure it gets properly handled by Makefile, for instance on a make clean
a84cace dropbear: Downgraded to 2015.66, every release since then has been broken one way or another
Check those hexadecimal numbers that are part of the filenames - they are the commit numbers at which point in time the builds were compiled.

I was working on improving my build script last night, figured I might just upload the generated files since I had them.

Code:
50ed89c Updated documentation
3329738 igmpproxy: Added support for config customization
4a8644f iptables: Added userspace NOTRACK library (MIPS)
ff2bd4c openssl: Updated to 1.0.2e
58f4a86 nettle: Make sure it gets properly handled by Makefile, for instance on a make clean
a84cace dropbear: Downgraded to 2015.66, every release since then has been broken one way or another


TY
 
Software development tends to be planned ahead of time. Most likely they sat down last year, decided what they were going to implement in 378, and completed that plan, and started planning and implementing new features for the 380 codebase, while only doing bugfixes to the 378 codebase - so they currently have two parallel development paths. That's typically a good time to have two separate versions, so you can develop both in parallel.

Makes sense to me from my experiences in software development. Thanks, good to think of their firmware architect(s) planning in this way. Us users tend to spend our time bumping into the trees, good that they're looking at the forest.
 
Upgraded my RT-AC66U.

No 5 GHz network according to my wireless devices; only 2.4?

The "control channel" is "auto" and the only other option is 0 (zero)?

Back to 378.56_2: 5 GHz works.
Exactly the same problem with the third test build.

Wish I had written down the control channel for 380.57a3, but thought it was 34 (auto, otherwise only offering 0), while 378.56_2 uses 36 (offers 36, 40, 44, and 48).

Unfortunately I also don't have time now to perform a factory reset. Hope to do that later this week.
 
Last edited:
Getting a ton of these in my log:

dnsmasq-dhcp[435]: DHCPACK(br0) iPhone
dnsmasq-dhcp[435]: DHCPREQUEST(br0)iPhone

Any ideas? I have assigned ip to the iphone and check of the phone confirms
it has the proper ip address.

CC
 
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