.56 development?

[Shonk]

My setup isnt the issue it has worked for some 15 years
the upstream dns is quite capable of resolving my whole domain inc lan

Forward local domain queries to upstream DNS = Yes

the reason for this

a.mydomain = router has a local record resolves fine doesnt forward upstream
b.mydomain = router has no local record forwards on to isp dns resolves fine
my dns is not the issue at all

i have run this setup on every firmware under the sun

openwrt
dd-wrt
netgear firmware
asus firmware
your firmware

all have worked fine up until today
there's a bug somewhere seriously
i was hunting down the problem all night last night

example of why its needed

nslookup
Default Server: aurora.shonk.org
Address: 2001:470:18a4::1

> aurora
Server: aurora.shonk.org
Address: 2001:470:18a4::1

Name: aurora.shonk.org (wasnt forwarded on)
Addresses: 2001:470:18a4::1
192.168.0.1

> www
Server: aurora.shonk.org
Address: 2001:470:18a4::1

Non-authoritative answer: (was forwarded on)
Name: ghs.googlehosted.com
Addresses: 2a00:1450:400c:c07::79
173.194.67.121
Aliases: www.shonk.org

as i have said i ruled out ipv6 by turning off ipv6 on a host

Your whole setup is the issue here, not the firmware.

Those two settings should NOT be enabled unless you have a very specific scenario that needs it In the case of the second option, it's typically when your upstream isn't your ISP but a Windows Server which is authoritative for your local domain. I can't think of any good scenario to use the first setting at all, but I vaguely remember someone asking for it for some arcane setup a long time ago.

And you should never set a local LAN domain to a public one. It WILL wreck havok on your network. Always use a local domain for your internal LAN, like shonk.lan. Otherwise, it means you expect the authoritative DNS on the Internet to be able to resolve every single LAN device on your LAN, and those would have to be non-routable IPs from your LAN.

 

[Correlor]

The web interface merely reports what's in clkfreq. If it says 600, then it means you have clkfreq set to 600.

I own a RT-AC68. Normaly 'clkfreq' survived a firmware update. With 56_alpha4 it seems it resets to "800,666" after booting. Setting it to "1200,800" , nvram commit and a reboot it does overclock my AC68 again but the firmware reports 800. The next reboot will undo the overclocking. (i have checked the bogomips).

 

[Shonk]

yes there's some reverting of clock speeds going on with the new builds not a problem
AC56U
1000 775 holds on reboots
1000 667 doesnt hold

AC66U
662 gets reverted at some point in the boot process
first boot cat /proc/cpuinfo shows 331 bogo mips
interface shows 600mhz

second boot its 300 bogo mips 600mhz all around

to get around it i edited the bootloader
its fine now

 

[RMerlin]

I own a RT-AC68. Normaly 'clkfreq' survived a firmware update. With 56_alpha4 it seems it resets to "800,666" after booting. Setting it to "1200,800" , nvram commit and a reboot it does overclock my AC68 again but the firmware reports 800. The next reboot will undo the overclocking. (i have checked the bogomips).

Most likely the CFE configures the cpu and ddr based on clkfreq at boot time, but afterward something else resets the clkfreq nvram setting back to the factory defaults. That's why you get the higher clock rate, but the webui reports the newly written clock rate as it's stored in nvram.

No idea what would be overwriting it, it's not something I've done, and with the amount of code Asus is shifting into closed source components, it's impossible to really track this down anymore.

 

[RMerlin]

yes there's some reverting of clock speeds going on with the new builds not a problem
AC56U
1000 775 holds on reboots
1000 667 doesnt hold

AC66U
662 gets reverted at some point in the boot process
first boot cat /proc/cpuinfo shows 331 bogo mips
interface shows 600mhz

second boot its 300 bogo mips 600mhz all around

to get around it i edited the bootloader
its fine now

667 is not a valid value. It should be 666.

  static unsigned int cpu_clock_table[] = {600, 800, 1000, 1200, 1400, 1600};
  static unsigned int ddr_clock_table[] = {333, 389, 400, 533, 666, 775, 800};

 

[RMerlin]

I suspect the clkfreq nvram gets reverted to the CFE values because it's not defined as a permanent nvram setting in shared/defaults.c. Could be something that Asus changed at some point in how they handle nvram entries that aren't defined with a default value.

If you compile your own firmware, you could try defining clkfreq in the list of default vars in shared/defaults.c. You'll have to take care of setting it to the correct values however, so an actual permanent solution would definitely be far more complicated than that.

 

[Shonk]

i will check if this http://hostname bug is asus introduced or merlin
will roll back to an asus firmware temp in a moment

 

[RMerlin]

i will check if this http://hostname bug is asus introduced or merlin
will roll back to an asus firmware temp in a moment

You realize that those two settings I said shouldn't be enabled except for specialized setups do not exist on the stock firmware, so you wouldn't be testing the same configuration?

 

[Shonk]

those setting are are irrelevant to the problem
its an asus introduced bug

its also doing it on asus 9135

also the qos page on firefox is an asus bug

You realize that those two settings I said shouldn't be enabled except for specialized setups do not exist on the stock firmware, so you wouldn't be testing the same configuration?

 

[Shonk]

ok to rule out anything at my end

mtd-erase -d nvram
powered down router (hardware)

Asus 9135 Firmware
powered up
set password
set wifi password
set samba hostname
set mac address clone to get ip

thats the only settings i changed

http://hostname is broken on the RT-AC66U
i dont know about other models

with regards to Advertise router's IP in addition to user-specified DNS
it shouldnt have been on i must have turned it on the other week by accident
doesnt matter though it wasnt anything to do with the problem, its off now

 

[ColinTaylor]

set samba hostname

Are you setting the Samba hostname to be the same as your routers DNS name?

I only ask because AFAIK by specifying an unqualified hostname (http://hostname) Windows will perform a name lookup using NetBIOS in preference to DNS. To guarantee use of DNS you must specify the domain, even if it's only a dot (for people that haven't created a local domain).

I'm not sure how this is relevant to your problem, but I thought I'd throw it in there.

 

[TurboFreak68]

It compiles as RT-AC87U_378.56_alpha4.trx. I just flashed it to my router. The router did not brick which is good, and everything seems to be working. I have only been running it for a little while, so I am not sure about performance. If you would like to try it, I have uploaded it to https://db.tt/41Lz9ltA

Thanks for sharing it out, Im running it too on my RT-AC87U for 5 hours with 13 clients online for the moment (PC´s, smartphones (both android/Iphone), Ipad Air, Samsung pad, Apple TV, LG Smart TV) and it seems more stable on 5Ghz now than before.

Update//
Up and running over a day now without any problem at all, before this FW version my AC client could disconnect/connet/disconnet/connect before working ok. This been awaken from hibernate, but now it connects straight away and stays connected. Client I use is a USB-AC56 from Asus.

 

[dsring]

Merlin has made some additional updates to GitHub. It is now in version Alpha 5. I went ahead and compiled it and flashed it to my RT-AC87R. Even though it is just an alpha version, it is working well. With Merlin revising the mDNSMonitor syslog priority, the system log errors have greatly reduced. As always, great work by Merlin. When the final .56 version releases, it will be a solid release. To share, I did upload RT-AC87U_378.56_alpha5.trx to https://db.tt/OaHtJNHN

 

[RMerlin]

The biggest show stopper right now is that httpd crashing issue reported on the official 9177 firmware discussion. I cannot release a firmware where some people might be left with an unmanageable router, which requires the use of the firmware recovery tool to recover.

 

[VANT]

maybe people who have problem with gui should try this beta and report to You ?

 

[nagle3092]

maybe people who have problem with gui should try this beta and report to You ?

Tried alpha4 and now alpha5 (from dsring) and it still giving me the same thing. I can roll back to 55 and everything works fine.

Maybe if someone could roll a version of the firmware without the updated web server changes? I know nothing for firmware development but my guess is maybe something broke with those fixes.

 

[TurboFreak68]

ok to rule out anything at my end

mtd-erase -d nvram
powered down router (hardware)

Asus 9135 Firmware
powered up
set password
set wifi password
set samba hostname
set mac address clone to get ip

thats the only settings i changed

http://hostname is broken on the RT-AC66U
i dont know about other models

with regards to Advertise router's IP in addition to user-specified DNS
it shouldnt have been on i must have turned it on the other week by accident
doesnt matter though it wasnt anything to do with the problem, its off now

I must ask do we discuss RMerlin 378.56_alpha FW version here or the one you type .9135 stock FW from Asus??

 

[Gitsum]

alpha 5 working ok for me.

 

[Shonk]

Its talking about the alpha ofc
I was just checking if the http://hostname bug on the rt-ac66u was asus or merlin sourced
turns out it was asus

would still be nice to see a fix from merlin though if he gets a chance

I must ask do we discuss RMerlin 378.56_alpha FW version here or the one you type .9135 stock FW from Asus??

 

[mromero]

Why the mad rush? I suggest everyone chill and await Merlin's release. The gentleman's track record on STABILITY is what has set his releases above all others, including the official builds!

The biggest show stopper right now is that httpd crashing issue reported on the official 9177 firmware discussion. I cannot release a firmware where some people might be left with an unmanageable router, which requires the use of the firmware recovery tool to recover.