Asuswrt-Merlin 378.56 Beta 1 is out

[L&LD]

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

http://www.snbforums.com/threads/asuswrt-merlin-378-56-beta-1-is-out.27593/page-8#post-211229

Not for all routers. Just the RT-AC66U.

 

[RMerlin]

Thanks for this firmware!!

Here i found bugs in GUI.Factory to default after flashing was done.

Im back to .55

Conntrack issue was the kernel missing an upstream merge, and still using the 5 days default.

(I have no less than four separate, parallel copies of the Linux kernel in this firmware project now...)

 

[RMerlin]

Dear Merlin, many thanks for the feedback. BTW, I think the problem was on the number of entries: I saw in this new firmware the Wireless MAC Address list is limited to 64 entries for the main WLANs and to 16 entries to the Virtual WLANs (is it possible to increase this limit?). With my 478.55 firmware I had like 30 entries and maybe this could have been a problem with the new limit of 16 entries for Virtual WLANs, since the entries have been imported both for main WLANs and Virtual one

I can try, but I'm facing two issues here:

1) The maclist is handled internally by the closed source wireless driver. I have no idea what's its own internal limit. I think that even 64 is already too high, I've had one report of random crashes a while back when someone was getting close to 30 entries. So I'm already facing the possiblity of having to reduce that 64 limit down to something like 24. Wireless driver is outside of my control.

2) The guest list would require a lot of changes to go beyond that limit of 16 MACs (it's not just a single value to change, there are arrays of 16 entries all over that page's Javascript).

So, bumping this to 64 is definitely out of the question, and I'm currently trying to decide if I'm dropping everything back to 16 as it's the only value I'm 100% sure is supported by the wireless driver, or move everything to 24 entries, and face having a hard time fixing any future changes by Asus to the Guest page (and potentially that page breaking every time they touch that code).

EDIT: After some digging, I came up with the value of 64 MACs as the limit built in the wireless driver. So it should, in theory, be safe to stick to that value (tho, IMHO, trying to manage that many MACs is probably a sign that you need to rethink your network - might be time to go with either Radius or a business-class router)

 

[DaveMishSr]

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

Did you ever read post #1? I'm deadly serious.

 

[DaveMishSr]

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*.

I second that. AAMOF, I use the following process BEFORE flashing:

1) Power off router.
2) Press & hold WPS button for at least 7 seconds.
3) Power the router on & continue to hold WPS button for 30 seconds.
4) Release the WPS button & power off the router.
5) Repeat at least once, more if the router has really ticked me off.

I have noticed one difference between my ac87r & ac68u. The 87 takes 20 seconds for the far left LED to pulsate the first time using that method and 5 seconds on each subsequent attempt. The 68 takes 5 seconds each and every time. Perhaps this is why some users report issues with resetting the factory defaults. However, my method results in a 100% flashing success rate (thus far). It's probably coincidence I'm sure.

Just sayin'.

EDIT: I then use that nifty nvram utility to restore settings in a jiffy!

 

[binggesoft]

I second that. AAMOF, I use the following process BEFORE flashing:

1) Power off router.
2) Press & hold WPS button for at least 7 seconds.
3) Power the router on & continue to hold WPS button for 30 seconds.
4) Release the WPS button & power off the router.
5) Repeat at least once, more if the router has really ticked me off.

I have noticed one difference between my ac87r & ac68u. The 87 takes 20 seconds for the far left LED to pulsate the first time using that method and 5 seconds on each subsequent attempt. The 68 takes 5 seconds each and every time. Perhaps this is why some users report issues with resetting the factory defaults. However, my method results in a 100% flashing success rate (thus far). It's probably coincidence I'm sure.

Just sayin'.

EDIT: I then use that nifty nvram utility to restore settings in a jiffy!

Friends,you use 2WAN it?

 

[RMerlin]

Yes Sir!
Think is coming from Syntax error

unreachable code after return statement
SyntaxError: missing ; before statement
ReferenceError: initial is not defined

After noticing that your browser was in French I switched mine to it as well, which triggered the error. It was caused by an apostrophe not being properly escaped. Fixed.

 

[RMerlin]

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.

I have a feeling it's an issue with the new watchdog Asus has been implementing lately for Dual WAN. Can you check your watchdog configuration? It might be too "twitchy" and incorrectly thinking that the primary Wan is randomly going down.

 

[RMerlin]

Can't get to overclock either one of my 87's using:
nvram set clkfreq=1200,800
nvram commit && reboot
Is there any other way?

Thanks for 56.b1 !

Fixing this is proving to be complicated. Therefore the recommend solution for the time being is to (re)set clkfreq in an init-start or a service-start script.

 

[hyungsub]

Qos -> system log click bug
(ASP DVI BUG?)

 

[RMerlin]

Qos -> system log click bug
(ASP DVI BUG?)

See Post #2.

 

[Martineau]

I have a feeling it's an issue with the new watchdog Asus has been implementing lately for Dual WAN. Can you check your watchdog configuration? It might be too "twitchy" and incorrectly thinking that the primary Wan is randomly going down.

Doh...should have spotted the consistent 5 second interval.....didn't quite make the connection with the watchdog timer.

 

[Martineau]

I have a script called by wan-start to invoke /usr/sbin/curl

Under this 378.56Beta1 my script fails to execute correctly and reports the following error

* error setting certificate verify locations:
  CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none

whereas reverting back to 378.55 the script correctly works as it reports:

  CAfile: /rom/ca-bundle.crt

 

[RMerlin]

I have a script called by wan-start to invoke /usr/sbin/curl

Under this 378.56Beta1 my script fails to execute correctly and reports the following error

* error setting certificate verify locations:
  CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none

whereas reverting back to 378.55 the script correctly works as it reports:

  CAfile: /rom/ca-bundle.crt

Thanks. Regression from the 8596 GPL merge (Asus changed the curl build rules and I lost the CA path specification then), fixed.

 

[mrdude]

@RMerlin.

I appreciate the effort you put into making this firmware but can you tell me what you changed that would cause RT Ac87u to get wireless dropouts since version 3.54_2

I tried the latest beta - ie 3.56 beta 1 but still had this issue (same since version 3.55) - I then tried the latest original firmware from Asus - but never got any dropouts from that firmware.

Somewhere between 3.54_2 and 3.55 firmware something broke wifi on the AC87U router to cause these dropouts. I have gone back to 3.54_2 as that firmware works fine, I would appreciate if you could at least acknowledge that there is a fault and if you are going to try and find it?

Thanks.

 

[jmantn]

Shot in the dark here but did you do a reset when changing firmware's?

 

[Zirescu]

@RMerlin.

I appreciate the effort you put into making this firmware but can you tell me what you changed that would cause RT Ac87u to get wireless dropouts since version 3.54_2

I tried the latest beta - ie 3.56 beta 1 but still had this issue (same since version 3.55) - I then tried the latest original firmware from Asus - but never got any dropouts from that firmware.

Somewhere between 3.54_2 and 3.55 firmware something broke wifi on the AC87U router to cause these dropouts. I have gone back to 3.54_2 as that firmware works fine, I would appreciate if you could at least acknowledge that there is a fault and if you are going to try and find it?

Thanks.

The Quantenna driver update is the likely culprit. If you didn't do a factory reset after each update you'll likely experience issues.

 

[mrdude]

The Quantenna driver update is the likely culprit. If you didn't do a factory reset after each update you'll likely experience issues.

Yes I did a factory reset, in version 3.55 my usb/sd card would unmount and wifi would dropout. Then I tried beta 3.56 - I still get wireless dropouts - where I am connected, but after a while wireless stops working, I need to disconnect on my laptop, then connect again for it to work.
The latest firmware from Asus works fine though without any problem, just something in RMerlins firmware causes this issue.
I like RMerlins firmware though It has some useful features that the original firmware doesn't have, I hope it gets fixed at some point - but 3.55 onwards is unusable for me, especially if trying to download something and my wifi is disconnected halfway through.
If you look in the 3.55 release thread - you'll see a few RTAC87u users have the same problem.

 

[binggesoft]

378.56beta2 firmware, why not fix 2WAN problem? Chinese users really need ah.

 

[RMerlin]

Yes I did a factory reset, in version 3.55 my usb/sd card would unmount and wifi would dropout. Then I tried beta 3.56 - I still get wireless dropouts - where I am connected, but after a while wireless stops working, I need to disconnect on my laptop, then connect again for it to work.
The latest firmware from Asus works fine though without any problem, just something in RMerlins firmware causes this issue.
I like RMerlins firmware though It has some useful features that the original firmware doesn't have, I hope it gets fixed at some point - but 3.55 onwards is unusable for me, especially if trying to download something and my wifi is disconnected halfway through.
If you look in the 3.55 release thread - you'll see a few RTAC87u users have the same problem.

The 378.56 wireless driver is exactly the same as Asus's 378_9177, and is completely different from the driver used in 378.55.

Wireless drivers are outside of my control. You get what Asus provides.