Asuswrt-Merlin 378.50 Beta 2 is out

[propergol]

An other guy said in a previous post that he did seen this after enabling jumbo frame.

 

[RMerlin]

Hey Merlin I installed your latest betahttp://www.mediafire.com/download/5s..._beta3b_ta.zip

So far so good but I cannot enable traffic analyzer. When I do the grey screen comes up stating the ip address has changed. I cannot access it until I reboot the router at the point, when I can get back in, traffic analyzer is off.

Most likely reason is you either failed to do the mandatory factory default reset when you first flashed a 378.50 beta, or you have disabled the JFFS partition where the TA database is saved.

Sent from my Nexus 4 using Tapatalk

 

[RMerlin]

I have to aske:
I have "HW acceleration Enabled (CTF only)"
But I have on another router: "HW acceleration Enabled (CTF+AF)"
What have I enabled to lose (CTF+AF)

octopus

FA is only supported by the AC87, AC3200 or the new AC68P. Also, I think Asus might have recently disabled it, probably for compatibility reasons - I'd have to recheck.

Sent from my Nexus 4 using Tapatalk

 

[JGrana]

I have been running beta3b for 7 hours. Running well. A Toshiba 1TB USB drive running in USB 3.0 mode is doing fine. USB 3.0 mode, blue light on the drive, etc.

I checked on the infamous:

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

I had 21 occurrences over a 4 day period. So far, none. I will continue to watch for them.
I enabled the Traffic Analyzer (I had turned it off for a few days). Again, no issues, it's collecting data but started up.

As I said, running well.

Thanks Merlin.

 

[cc666]

beta3b_ta.zip

Running this also for several hours on mt RT-AC87. So far perfect.
Finally the kernel: br0: received packet on vlan1 with own address as source address is gone!

The 5 ghz channel seems a bit stronger. Where I was getting a 243 connection I now get a solid 270. USB transfer as fast as stock. IPV6 6 to 4 tunnel is perfect. Vodo stream test on 2.4 channel burries the needle in the connection test. Before it was 3/4. So far rock solid! THANK YOU MERLIN!
This could be the released version..........

CC

 

[RMerlin]

Running this also for several hours on mt RT-AC87. So far perfect.
Finally the kernel: br0: received packet on vlan1 with own address as source address is gone!

The 5 ghz channel seems a bit stronger. Where I was getting a 243 connection I now get a solid 270. USB transfer as fast as stock. IPV6 6 to 4 tunnel is perfect. Vodo stream test on 2.4 channel burries the needle in the connection test. Before it was 3/4. So far rock solid! THANK YOU MERLIN!
This could be the released version..........

4129 did come with a new Quantenna firmware, tho it's still the same driver version. Asus might have tweaked some things in it, I don't know what was changed, only that the binary FW image itself was different.

I don't know if Asus actually resolved the vlan1 issue, as I didn't get any changelog with the new GPL. I know that they were aware of the issue and had been working on it, so it's possible they might have finally found the cause. Only time will tell (as that message hasn't appeared on my own router in weeks).

 

[JohnOCFII]

I've been running a mix of Beta 1 and Beta 2 since January 31st on an RT-N66. All seems good.

Uptime and wireless signal has been solid. Performance has been tested good on 2.4 GHz, 5 GHz, and across to the wired network using iperf.

In terms of features, I've tried with and without per-IP statistics. I use lots of DHCP reservations (15) (I wish they didn't call them static...). I have OpenVPN server set up and tested regularly. I have a mix of 25 2.4, 5.0, and wired devices including Android, iOS, MacOS, Linux, Windows, and VMware hosts. I have a number of port forwards configured too. I also have all the interfaces monitored with SNMP from a remote host. I also have a USB memory stick in use for logs. I also use DDNS with dyndns.org successfully. I'm on Comcast. I don't have IPv6 configured.

Anyway -- not a very scientific Beta user report, but I'm very pleased.

Thank You.

John

 

[snbdora]

Any idea why the Mac address is same for all interfaces?

 

[mark0263]

I don't know if Asus actually resolved the vlan1 issue, as I didn't get any changelog with the new GPL. I know that they were aware of the issue and had been working on it, so it's possible they might have finally found the cause. Only time will tell (as that message hasn't appeared on my own router in weeks).

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

 

[RMerlin]

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

Your messages are a bit different tho, as they refer to eth1 at times. Make sure you don't have a device that's connected both over 2.4 GHz and Ethernet at the same time.

 

[mark0263]

Your messages are a bit different tho, as they refer to eth1 at times. Make sure you don't have a device that's connected both over 2.4 GHz and Ethernet at the same time.

You are correct - I had one laptop on a port replicator that was also on wifi. I've fixed that - hopefully no more messages in the logs.

Thanks for the insight!
Mark

 

[eak]

openvpn --show-tls

I have a favor to ask. Could someone with the beta installed login via ssh and do "openvpn --show-tls". I'd like to know if the new release includes TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 or TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384? They aren't in 376.49_5.

The best TLS crypto is ECDHE and AES/GCM, but the current Merlin doesn't allow that (best one can do is fall back on CBC mode, e.g. TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA).

 

[RMerlin]

I have a favor to ask. Could someone with the beta installed login via ssh and do "openvpn --show-tls". I'd like to know if the new release includes TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 or TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384? They aren't in 376.49_5.

The best TLS crypto is ECDHE and AES/GCM, but the current Merlin doesn't allow that (best one can do is fall back on CBC mode, e.g. TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA).

Those are TLS 1.2 ciphers, which are not supported by OpenSSL 1.0.0.

 

[kasz]

After a new upgrade to the latest beta, all works fine again. I have same throughput as previous beta.

In the end it wasn't needed to perform factory reset, only upgrade again.

 

[greg50]

After a new upgrade to the latest beta, all works fine again. I have same throughput as previous beta.

In the end it wasn't needed to perform factory reset, only upgrade again.

There is a final version of it, upgrade to that.

 

[mattiL]

This is not going to make you any happier:

Feb 7 06:54:00 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 06:54:00 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 06:54:00 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 07:53:58 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 07:53:58 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 07:53:58 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 08:53:56 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 08:53:56 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 08:53:56 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 09:53:54 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 09:53:54 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 09:53:54 kernel: br0: received packet on vlan1 with own address as source address

Looking back at the log these messages seems to be cyclic every hour.

Running for 16 hours 17 minutes on this firmware.

(RT-AC87U on 378.50-beta3_ta)

 

[themrindy]

Website

Hi!

Im using the 378.50_0 firmware so far so good! Thanks Merlin!

I though have an issue with the logout button for the AICloud website. When pressing logout nothing happens...is that closed source?

ps. Regarding my former posts about WAN download-speed I now (after 378.50_0) I get 580/700 so increase of 180Mbit and the CPU is also only utils about 80%.ds.

Regards,
Christian

 

[dfran1]

On beta3 for the ac-rt87
I get
Feb 7 06:49:24 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 06:49:25 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 06:49:26 kernel: br0: received packet on vlan1 with own address as source address
Feb 7 06:49:27 kernel: br0: received packet on vlan1 with own address as source address

Also streaming from a dish network hopper to an ipad, the ipad gets video drops, my wife got so fed up with it last night she just went to bed.

I tried this morning and saw the dops myself.
I have not used beta 378.50_3_ta long enough to find problem below.

on beta 2 (I do not know if this went into final).
After 24hours both my ipad and iphone, I had to shut wifi down and turn back on to get wifi access, it said connected but nothing was working either LAN or WAN, on 5 GHz.

I loaded the beta 2 by asus restore utility, and a WPS reset.

I loaded beta 3 thru gui (web browser) and WPS reset.
All tests done with settings below
Restoring all settings manually, NO USB drives attached, 2 port forwards, 2 Manually Assigned IP around the DHCP list, wpa2 personal for 2.4GHz, guest 2.4GHz, and 5GHz, with a DDNS that is all NOTHING else.

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??

EDIT:
Also at about the 24 hour mark, on beta 2 so far, PS4 LAG, reboot router and fine again. not sure yet on beta 3.

 

[Ritzie]

Most likely reason is you either failed to do the mandatory factory default reset when you first flashed a 378.50 beta, or you have disabled the JFFS partition where the TA database is saved.

Sent from my Nexus 4 using Tapatalk

I didn't have JFFS partition enabled. Thanks Merlin.

 

[highwire]

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??

Try not to feel too bad. I have two issues with 378.50 (one on a 66U and a different one on a 87U) and have had no responses or feedback either. I guess sometimes our issues are just too unique.

As for your particular issue, sorry, but I'm just not seeing it on my 87U.