Asuswrt-Merlin 378.50 Beta 2 is out

[duckymcse]

My RT-AC87U with beta 2 had been up and running for 6 days and 15 hours without any issue so far. It's been rock solid.
I do see the "kernel: br0: received packet on vlan1 with own address as source address" on the system log when I use my LG Bluray player (wired network) to stream from my USB3.0 hard drive to play 1080P MKV DTS movies. Despite the error show up, my router work fine with no disconnect or slow down with 2.4/5G wireless connection from multiple devices.
I think my router is stable enough that I even cut off the UPC send to ASUS to get the rebate. I purchased mine like 2 weeks ago.
I wonder if your is defective. Give ASUS a call and get a replacement.
I don't know, try to replace your Ethernet cable from the modem to the router and see if it help.

Just a question
Am I the only one actually using this router, the only reason I ask is no one else seems to be having these problems, or they are not reporting them??
.

 

[johnpramod]

What is that about?

 

[DEJ710]

Mr

Howdy folks,

For the main list of changes in 378.50, please see the first beta thread.

This thread is for the 378.50 Beta 2 release. Thanks to everyone's feedback with beta 1 a number of issues were found and resolved. Here's the list of changes over Beta 1:

378.50 Beta 2 (31-Jan-2015)
   - NEW: Added custom config and postconf support for avahi, netatalk 
          and mt-daapd (iTunes server).
   - CHANGED: Moved the AC68U CFE update process to the same location
              as in GPL 3626 to see if it works more consistently.
   - FIXED: Non-DPI build of AC56U had incompatible Tuxera modules
   - FIXED: vsftpd wouldn't start if you had IPv6 enabled.
   - FIXED: Asus had disabled the NAT loopback fix on MIPS's iptables
            in GPL 3762.  Re-enabled.
   - FIXED: Wireless clients that hadn't communicated in a while wouldn't
            be properly shown on the Wireless log (patch by pinwing)
   - FIXED: QoS rules weren't applied properly when IPv6 was enabled
            (was changed in recent GPL - reverted it)
   - FIXED: Can't apply a Custom DDNS if you don't have something entered
            in the username/password fields (shown in other DDNS services)
   - FIXED: NFS page wasn't properly loading

In addition, a fix was applied to the System page where Internet Explorer users wouldn't see the additionnal JFFS options until they toggled the JFFS partition off/on.

All supported models are currently available on Mediafire in the Beta folders. Also, an experimental DPI-enabled build for the RT-AC56U has been uploaded (with a version label of 378.50-beta2_dpi).

Please post your feedback and bug reports here. Don't forget to mention your router model.

A factory default reset is only required if you were not already running 378.50 beta 1.

Downloads are here.
Changelog is here.

I have noticed that several devices in the Network Map Client Status area show their IP addresses as Static when they are actually DHCP (Reserved). Is this correct?

 

[RMerlin]

I have noticed that several devices in the Network Map Client Status area show their IP addresses as Static when they are actually DHCP (Reserved). Is this correct?

Known issue, mentioned by Asus in their own changelog.

 

[DEJ710]

Known issue, mentioned by Asus in their own changelog.

Thanks for your response Merlin. Any fix planned for this that you know of?

 

[RMerlin]

Thanks for your response Merlin. Any fix planned for this that you know of?

I know that the new Networkmap is still a work-in-progress on their end, so I'm sure they'll eventually resolve it (if they haven't already).

 

[DEJ710]

Howdy folks,

For the main list of changes in 378.50, please see the first beta thread.

This thread is for the 378.50 Beta 2 release. Thanks to everyone's feedback with beta 1 a number of issues were found and resolved. Here's the list of changes over Beta 1:

378.50 Beta 2 (31-Jan-2015)
   - NEW: Added custom config and postconf support for avahi, netatalk 
          and mt-daapd (iTunes server).
   - CHANGED: Moved the AC68U CFE update process to the same location
              as in GPL 3626 to see if it works more consistently.
   - FIXED: Non-DPI build of AC56U had incompatible Tuxera modules
   - FIXED: vsftpd wouldn't start if you had IPv6 enabled.
   - FIXED: Asus had disabled the NAT loopback fix on MIPS's iptables
            in GPL 3762.  Re-enabled.
   - FIXED: Wireless clients that hadn't communicated in a while wouldn't
            be properly shown on the Wireless log (patch by pinwing)
   - FIXED: QoS rules weren't applied properly when IPv6 was enabled
            (was changed in recent GPL - reverted it)
   - FIXED: Can't apply a Custom DDNS if you don't have something entered
            in the username/password fields (shown in other DDNS services)
   - FIXED: NFS page wasn't properly loading

In addition, a fix was applied to the System page where Internet Explorer users wouldn't see the additionnal JFFS options until they toggled the JFFS partition off/on.

All supported models are currently available on Mediafire in the Beta folders. Also, an experimental DPI-enabled build for the RT-AC56U has been uploaded (with a version label of 378.50-beta2_dpi).

Please post your feedback and bug reports here. Don't forget to mention your router model.

A factory default reset is only required if you were not already running 378.50 beta 1.

Downloads are here.
Changelog is here.

Hi RMerlin,

Any idea what might be causing the following errors (over and over) in the log?

mDNSProxyResponderPosix: GetLargeResourceRecord: opt 65002 optlen 8 wrong

A quick google didn't turn up anything useful.

 

[Martineau]

Hi RMerlin,

Any idea what might be causing the following errors (over and over) in the log?

mDNSProxyResponderPosix: GetLargeResourceRecord: opt 65002 optlen 8 wrong

A quick google didn't turn up anything useful.

Perhaps this is one explanation..

http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_perf/getlargeresourcerecord-opt-65002-optlen-8-wrong/c8ed8f34-7197-4c42-b9d3-aacae0073777

 

[RogerSC]

Perhaps this is one explanation..

http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_perf/getlargeresourcerecord-opt-65002-optlen-8-wrong/c8ed8f34-7197-4c42-b9d3-aacae0073777

If this is the problem, note that iTunes can run on Windows without bonjour, and also without several other pieces of the full iTunes install archive. There's information on the internet about how to do this, but basically, if you're not big into the Apple ecology, you can just use 7-zip to take apart the full iTunes download install archive (145MB). Then don't install bonjour or quicktime and a couple other pieces. You can also get a reduced size quicktime substitute that keeps iTunes happy. The net result is that you end up with a functional iTunes that handles your Apple mobile devices and can also take care of your music and podcast library and download from the iTunes store, with less impact on the system that you install it on and your network.

I've been doing this for years. At first, the iTunes download was "only" 85MB, and now it's up to 145MB. That's a lot for what it does for me. Of course, if you use it for more then you won't be able to do this.

 

[DEJ710]

Mr

Hi RMerlin,

Any idea what might be causing the following errors (over and over) in the log?

mDNSProxyResponderPosix: GetLargeResourceRecord: opt 65002 optlen 8 wrong

A quick google didn't turn up anything useful.

Thanks, have stopped the Bonjour service and changed the startup type to Demand Start - error has now gone.

What about this one over and over then?

kernel: vlan1: received packet with own address as source address

 

[bknusa]

Been running the new 3a beta for a couple of hours on RT-AC87U - still seeing these errors in my log:

Feb  6 19:12:28 kernel: br0: received packet on eth1 with own address as source address
Feb  6 19:45:22 kernel: br0: received packet on eth1 with own address as source address
Feb  6 19:54:35 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:05:08 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:05:08 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:05:08 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:06:40 kernel: htb: htb qdisc 10: is non-work-conserving?
Feb  6 20:09:12 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:10:36 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:10:52 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:11:20 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:16:09 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:37:54 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:39:54 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:41:55 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:43:55 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 20:47:30 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:50:03 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:50:13 kernel: br0: received packet on eth1 with own address as source address
Feb  6 20:50:50 kernel: br0: received packet on eth1 with own address as source address
Feb  6 21:03:18 kernel: br0: received packet on eth1 with own address as source address
Feb  6 21:04:18 kernel: htb: htb qdisc 17: is non-work-conserving?
Feb  6 21:04:45 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 21:04:45 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 21:04:45 kernel: br0: received packet on vlan1 with own address as source address
Feb  6 21:08:49 kernel: br0: received packet on eth1 with own address as source address
Feb  6 21:15:13 kernel: htb: htb qdisc 16: is non-work-conserving?
Feb  6 21:22:32 kernel: htb: htb qdisc 11: is non-work-conserving?

Everything seems to be working fine - a good mixture of iPhones, wireless laptops, etc.



I am running behind a u-verse modem in pass-thru mode, which I suspect may be part of the issue with the own address errors.

Thanks for the updated beta!

Mark

Make sure that you have a different SSID for the 2.4 and 5.0Gig Wifi bands