Asuswrt-Merlin 378.56 Beta 1 is out

[charlie2alpha]

I'm only using one of those surge protected power outlets, I hope that'll offer enough protection against damaged hardware.

What I was always wondering (and since you're using a UPS for your modem as well): Would a UPS connected to a modem ensure that you've still got broadband connectivity in a case of power outage? I'm completely clueless regarding these things, but what I'm wondering is whether it is common that the cabinet on the street which you're connected to, has an independent power supply. Otherwise I'd imagine that in case of an outage in your part of town, you'd lose your broadband connectivity anyway.

Yes, it has happened a few times, I still have internet until my UPS battery runs out. They probably have their own UPS on the exchange (I'm connected directly there, no cabinet with mini-DSLAM here).

 

[easyriider]

With this beta I also had issues with ntp which will not syncing with eu.pool.ntp.org so I switched back to 378.55.

But one positive difference between this new beta and the previous version is the speed via wifi. With this beta I get transfer speeds of around 30mbit/sec on a 40mbit cable connection. On the previous versions I got wifi transfer speeds between 10 and 15 mbit/sec.

This is all tested on a Nexus 10 close to my RT-AC56U router. I don't have computers with wifi to test it.

 

[RMerlin]

System log active connections showing established connections for devices not even connected to the network, I dont regularly look at this page but cant say I have noticed this before.

This is just a straight dump of the kernel's conntrack table.

 

[bilboSNB]

Ah right, I was mixing it up with the netstat page.

 

[My_dogs_White]

I've updated wirelessly for over a year. Not one issue. Too lazy to find Ethernet cord


Sent from my iPhone using Tapatalk

I have done both, Ethernet and wirelessly, doesn't seem to be any difference. In my experience, do whatever is more convenient.

 

[RogueSpear]

It's looks like the NTP sync isn't working in this beta:

Oct 13 17:33:19 hour monitor: daemon is starting
Oct 13 17:33:19 hour monitor: ntp is not syn
Oct 13 17:33:49 hour monitor: daemon is starting
Oct 13 17:33:49 hour monitor: ntp is not syn
Oct 13 17:34:19 hour monitor: daemon is starting
Oct 13 17:34:19 hour monitor: ntp is not syn
Oct 13 17:34:49 hour monitor: daemon is starting
Oct 13 17:34:49 hour monitor: ntp is not syn

Time setting via SSH works fine

date -s 2015.10.13-17:38

I always used the NTP pool nl.pool.ntp.org without problems with the previous firmwares, but now this keeps trying every half a minute.

Is this a known problem or is it unique?

There's definitely something going on with NTP. I'm using the dnscrypt-proxy and hostip binaries from lancethepants. I have several pool.ntp.org entries at the top of my hosts.add file, but even if I hardcode one of those IPs right in the GUI, NTP will not work when I have the following wan-start script in place:

#!/bin/sh

logger -t $(basename $0) "started [$$]"

/bin/pidof dnscrypt-proxy > /dev/null 2>&1 || \
(

  # restart NTP client to eliminate 4-5 mins delay

  killall ntp
  sleep 1
  service restart_dnsmasq
  service restart_ntpc
  sleep 5


  # wait up to 5 minutes to make sure the router has the correct time

  tmax=300
  i=0
  while [ $i -le $tmax ]
  do
  if [ "$(nvram get ntp_ready)" -eq "1" ]
  then
  break
  fi
  logger "Waiting for correct time to be set."
  sleep 1
  i=`expr $i + 1`
  done


  # dnscrypt-proxy requires the correct time for certificate validation

  /jffs/bin/dnscrypt-proxy --local-address=127.0.0.1:60053 --ephemeral-keys --resolver-name=dnscrypt.org-fr --resolvers-list=/jffs/bin/dnscrypt-resolvers.csv --daemonize
  /jffs/bin/dnscrypt-proxy --local-address=127.0.0.1:60054 --ephemeral-keys --resolver-name=soltysiak --resolvers-list=/jffs/bin/dnscrypt-resolvers.csv --daemonize
)

I get the same log entries that I quoted from MegaTronics. So I'm not sure if it's a bug or if the lancethepants binaries need to be updated somehow, but as soon as I eliminate that script, NTP is happy again. Oh and I've tried setting both Google and OpenDNS (Cisco) as my DNS servers in the GUI.

 

[charlie2alpha]

@RMerlin has updated the ntp code with a fix in his git since beta 1, you'll need to wait for beta 2 or compile it yourself if able.

 

[TimmyL]

Known issues:

• No RT-N66U build: new Asus GPL required (cannot fix)
• Battery drain on the RT-AC87U wifi devices: QTN issue, they are (still) fighting with it. (cannot fix)
• Adaptive QoS Bandwidth page has an unusually large clickable area for the Apply button (old issue that came back) FIXED
• QoS page layout shifted up on Firefox FIXED
• Various issues with the RT-AC66U (was a bad build, FIXED)

Asus just released a new Firmware version 3.0.0.4.378.9235 for RT-N66U, can it help ?

 

[charlie2alpha]

Asus just released a new Firmware version 3.0.0.4.378.9235 for RT-N66U, can it help ?

No unless they also released the relevant source code for it.

Sent from my Nexus 9 using Tapatalk

 

[Martineau]

As usual when implementing a Beta firmware, I'm sure there are event messages in the Syslog that may have always appeared, but simply come under (renewed) scrutiny.

However, this short Syslog sequence is almost as-is, although for brevity I have deleted two lines that were basic firewall DROP messages.

Oct 15 11:06:51 RT-AC56U kern.notice WAN(0) Connection: WAN was exceptionally disconnected.
Oct 15 11:06:56 RT-AC56U kern.notice WAN(0) Connection: WAN was restored.
Oct 15 11:31:58 RT-AC56U kern.notice WAN(0) Connection: WAN was exceptionally disconnected.
Oct 15 11:32:03 RT-AC56U kern.notice WAN(0) Connection: WAN was restored.
Oct 15 12:00:01 RT-AC56U cron.info crond[477]: crond: USER admin pid 2389 cmd /jffs/scripts/TrackUPTime.sh
Oct 15 12:00:01 RT-AC56U user.warn (TrackUPTime.sh): 2390 RT-AC56U Uptime logged to /tmp/mnt/RT-AC56U/Session_UPTIME.txt
Oct 15 12:17:08 RT-AC56U kern.notice WAN(0) Connection: WAN was exceptionally disconnected.
Oct 15 12:17:13 RT-AC56U kern.notice WAN(0) Connection: WAN was restored.
Oct 15 12:37:07 RT-AC56U kern.notice WAN(0) Connection: WAN was exceptionally disconnected.
Oct 15 12:37:12 RT-AC56U kern.notice WAN(0) Connection: WAN was restored.
Oct 15 13:00:01 RT-AC56U cron.info crond[477]: crond: USER admin pid 15249 cmd /jffs/scripts/TrackUPTime.sh
Oct 15 13:00:01 RT-AC56U user.warn (TrackUPTime.sh): 15250 RT-AC56U Uptime logged to /tmp/mnt/RT-AC56U/Session_UPTIME.txt
Oct 15 13:02:14 RT-AC56U kern.notice WAN(0) Connection: WAN was exceptionally disconnected.
Oct 15 13:02:19 RT-AC56U kern.notice WAN(0) Connection: WAN was restored.
Oct 15 13:07:16 RT-AC56U kern.notice WAN(0) Connection: WAN was exceptionally disconnected.
Oct 15 13:07:26 RT-AC56U kern.notice WAN(0) Connection: WAN was restored.

I have a 20Mb fibre connection and as I worked from home today (over the company VPN with VOIP PC phones), I'm fairly certain that I wasn't aware that the WAN actually physically dropped for any of the 6 reported disconnects.... in fact I was actively participating in an internal interactive Lync session between 10:30 and 11:50.

Suspiciously, the short consistent 5 second gap between the disconnect/reconnect messages (together with no evidence that the wan-start/firewall-start/nat-start scripts were invoked) imply that these are not real events?

However, I do have a ZTE USB modem attached for DUAL-WAN failover and simply wanted to ask if anyone else has observed similar sequences of potentially 'misleading' messages.

NOTE: Successfully running 378.56 Beta1 for approx. 50 hours.

 

[RogueSpear]

@RMerlin has updated the ntp code with a fix in his git since beta 1, you'll need to wait for beta 2 or compile it yourself if able.

Sorry about that.. I didn't notice. I'll have to wait for beta 2. It's been a number of years since I've compiled anything and I don't want to jump back into it with this particular thing.

 

[jim769]

Strange issue trying to flash this build on my 68R from Johns fork and it will not take. It goes through the flash process then when it completes it still on the old fork version. I believe my boot loader is up to date 1.0.2.0. Any ideas whats going on never had this problem before and i have flashed a lot of firmwares over time.

 

[szwistak]

Known issues:

• No RT-N66U build: new Asus GPL required (cannot fix)
• Battery drain on the RT-AC87U wifi devices: QTN issue, they are (still) fighting with it. (cannot fix)
• Adaptive QoS Bandwidth page has an unusually large clickable area for the Apply button (old issue that came back) FIXED
• QoS page layout shifted up on Firefox FIXED
• Various issues with the RT-AC66U (was a bad build, FIXED)

do you have new build for RT-AC66U ready somewhere?

 

[RogerSC]

Strange issue trying to flash this build on my 68R from Johns fork and it will not take. It goes through the flash process then when it completes it still on the old fork version. I believe my boot loader is up to date 1.0.2.0. Any ideas whats going on never had this problem before and i have flashed a lot of firmwares over time.

I'd suggest resetting your router to factory defaults before flashing, if you're having a problem. Maybe more than one reset before flashing.

Have you tried the firmware restoration app route yet?

I've had this happen with routers as well, and fiddling with things has generally turned the trick *smile*.

 

[Martineau]

do you have new build for RT-AC66U ready somewhere?

Why not read the 1st post of this thread?

 

[jim769]

I'd suggest resetting your router to factory defaults before flashing, if you're having a problem. Maybe more than one reset before flashing.

Have you tried the firmware restoration app route yet?

I've had this happen with routers as well, and fiddling with things has generally turned the trick *smile*.

Thanks i finally got it to flash strange even the latest stock firmware would not work i ended up going back and flashing Merlin 378.53 it took then reset and flashed to 378.56 and it worked i have a feeling it had something to do with the boot loader update but who knows.

 

[szwistak]

Why not read the 1st post of this thread?

link for fixed build for AC66U?

 

[XIII]

Another ntp issue here?

Downgraded my RT-AC66U to 378.55 (as advised by RMerlin due to the broken build); ntp issue is gone.

 

[Chazall1]

Same issue with the beta build. I went back to 378.55 and running fine.

 

[jim769]

Downgraded my RT-AC66U to 378.55 (as advised by RMerlin due to the broken build); ntp issue is gone.

At what post in this thread did Merlin declare this 56 as a broken build ?