[Preview] Early Asuswrt-Merlin 384.6 test builds are available

[kfp]

No, neither. The setup is fairly vanilla, except OVPN server is running.

I have 2 Apple Time Capsules connected by Ethernet, set up as APs. Not sure if that is relevant.

UPnP enabled? Do you use any peer-to-peer applications like Dropbox/Syncthing?

Basically what we’ve seen is these applications, being decentralized, have to discover other nodes and they end up discovering and peering with itself via the port opened through UPnP or port forward.

 

[PolarBear]

UPnP enabled? Do you use any peer-to-peer applications like Dropbox/Syncthing?
.

UPnP settings left as the default. WhatsApp installed on iPhone clients. The youngsters sometimes use Spotify, but I think not at the time of these log entries.

No Dropbox or Syncthing.

There are no apparent performance problems and the log file entries do not worry me, I am just a bit puzzled and thought I should mention it already during the 384.6 development phase rather than later on.

 

[kfp]

UPnP settings left as the default. WhatsApp installed on iPhone clients. The youngsters sometimes use Spotify, but I think not at the time of these log entries.

No Dropbox or Syncthing.

There are no apparent performance problems and the log file entries do not worry me, I am just a bit puzzled and thought I should mention it already during the 384.6 development phase rather than later on.

If you left it default then it’s on.

This is a known behaviour and since it doesn’t really impact function so not a lot of work has been put into investigating this.

It’s basically the router kernel telling you that “hey there is this host talking to itself and that’s weird!” Since normally if traffic is local to a host it’ll be over the loopback device which means the router won’t ever see it. @

 

[Treadler]

Ok, I was tasting victory too early: today, after I upgraded the FW to the latest Alpha2 during the WE, the Wireless Scheduler didn't woked as expected and the WiFi stayed on all the night. Mi WiFi scheduler has the following settings:

Monday-Friday: OFF from 1.00 AM to 6.00 AM
All other hours: ON

@RMerlin : just for curiosity, is that issue related to the closed source WiFi components?

My experience: scheduling, both of wireless, & rebooting, has been intermittently broken on all firmwares for a long while now.
Works sometimes, but unreliable.

 

[juched]

384.alpha2-g5b076fc on RT-AC86U - running for 4 days with no problems at all. Channels selected manually for both radios.

A few unexplained log entries but apart from that, everything seems to be working fine.

Jul 3 19:54:13 kernel: br0: received packet on eth5 with own address as source address
Jul 3 20:26:05 kernel: br0: received packet on eth5 with own address as source address
Jul 3 20:52:26 kernel: br0: received packet on eth6 with own address as source address
Jul 3 20:52:32 kernel: br0: received packet on eth5 with own address as source address
Jul 3 21:57:30 kernel: br0: received packet on eth5 with own address as source address
Jul 3 22:38:05 kernel: br0: received packet on eth5 with own address as source address
Jul 4 02:56:08 kernel: br0: received packet on eth5 with own address as source address
Jul 4 09:07:27 kernel: br0: received packet on eth5 with own address as source address
Jul 4 10:27:56 kernel: br0: received packet on eth5 with own address as source address
Jul 4 10:48:58 kernel: br0: received packet on eth5 with own address as source address
Jul 4 14:27:42 kernel: br0: received packet on eth5 with own address as source address
Jul 4 14:28:44 kernel: br0: received packet on eth6 with own address as source address
Jul 4 14:29:06 kernel: br0: received packet on eth6 with own address as source address

Do you have a guest network setup? I had a similar issue with a guest network having the same MAC.


Sent from my iPhone using Tapatalk

 

[PolarBear]

Do you have a guest network setup? I had a similar issue with a guest network having the same MAC.

Yes, Guest 1 is enabled, with the MAC filter left as the default "Disable". The same SSID is used for both 2.4 and 5.

For non-guest, I use a different SSID, but again the same SSID for both radios.

I also have 2 APs connected to the main AC-RT86U with Ethernet cables. For non-guest, both APs also use the same SSID as the main router, but on different channels. The APs have no guest set up.

 

[juched]

Yes, Guest 1 is enabled, with the MAC filter left as the default "Disable". The same SSID is used for both 2.4 and 5.

For non-guest, I use a different SSID, but again the same SSID for both radios.

I also have 2 APs connected to the main AC-RT86U with Ethernet cables. For non-guest, both APs also use the same SSID as the main router, but on different channels. The APs have no guest set up.

Try turning off guest networks and see if the error message goes away. This doesn’t seem to impact things but may help. Just a guess.


Sent from my iPhone using Tapatalk

 

[kfp]

Yes, Guest 1 is enabled, with the MAC filter left as the default "Disable". The same SSID is used for both 2.4 and 5.

For non-guest, I use a different SSID, but again the same SSID for both radios.

I also have 2 APs connected to the main AC-RT86U with Ethernet cables. For non-guest, both APs also use the same SSID as the main router, but on different channels. The APs have no guest set up.

Pretty sure it’s coming the two Time Capsules but whether it’s from clients connected to it or some other service on the APs themselves I’m not too sure.

I don’t think it’s the guest networks, those would show up as wl0.1 etc. but it’s eth5 and eth6 in the logs.

 

[skeal]

Yes, Guest 1 is enabled, with the MAC filter left as the default "Disable". The same SSID is used for both 2.4 and 5.

For non-guest, I use a different SSID, but again the same SSID for both radios.

I also have 2 APs connected to the main AC-RT86U with Ethernet cables. For non-guest, both APs also use the same SSID as the main router, but on different channels. The APs have no guest set up.

I had a problem with the same log entry and found that if you don't use IFTTT or Alexa then you can disable "asusnat tunnel" setting in the tools other settings tab. Set this to "yes". It helped me.

 

[PolarBear]

Well, httpd is still having, what appears to be, memory leak issues on my 86U running 384.6_alpha2-g5b076fc87. httpd continues to consume more and more memory (not a lot mind you) until it gets to near 7888 kB and then the GUI is unresponsive. Once I restart httpd, then it starts over again at "VmRSS: 3540 kB" and the GUI works well and I start over again, with the httpd memory rising until that magical limit (near 8000 kb).

RT-AC86U with 384.6_alpha2-g5b076fc87, uptime nearly 5 days. After clicking round the GUI, after about the 20th click it froze trying to access the Dual WAN page*. Firefox message "performing a TLS handshake" and no further progress. SSH in with Putty, then service stop-httpd and service start-httpd, could log on again without problem.

*I am not using Dual WAN, just wanted to look at the configuration page.

 

[matthew_eli]

My experience: scheduling, both of wireless, & rebooting, has been intermittently broken on all firmwares for a long while now.
Works sometimes, but unreliable.

The same for me; I don't use the reboot scheduler, but the wireless scheduler has the same behaviour you describe

 

[agilani]

384.alpha2-g5b076fc on RT-AC86U - running for 4 days with no problems at all. Channels selected manually for both radios.

A few unexplained log entries but apart from that, everything seems to be working fine.

Jul 3 19:54:13 kernel: br0: received packet on eth5 with own address as source address
Jul 3 20:26:05 kernel: br0: received packet on eth5 with own address as source address
Jul 3 20:52:26 kernel: br0: received packet on eth6 with own address as source address
Jul 3 20:52:32 kernel: br0: received packet on eth5 with own address as source address
Jul 3 21:57:30 kernel: br0: received packet on eth5 with own address as source address
Jul 3 22:38:05 kernel: br0: received packet on eth5 with own address as source address
Jul 4 02:56:08 kernel: br0: received packet on eth5 with own address as source address
Jul 4 09:07:27 kernel: br0: received packet on eth5 with own address as source address
Jul 4 10:27:56 kernel: br0: received packet on eth5 with own address as source address
Jul 4 10:48:58 kernel: br0: received packet on eth5 with own address as source address
Jul 4 14:27:42 kernel: br0: received packet on eth5 with own address as source address
Jul 4 14:28:44 kernel: br0: received packet on eth6 with own address as source address
Jul 4 14:29:06 kernel: br0: received packet on eth6 with own address as source address

I have similar events in my logs files since upgrading to the 384 code base. As far as i can tell...its indicates either a loop in the network or maybe its expected behavior since almost all of the interfaces on the asus device have the same mac address.

I do have port forwarding enabled.

 

[Lotta Cox]

Anyone seen this in the logs or know what it is?

https://pastebin.com/z5esUBne

 

[Jon555]

I am considering updating to 384.6 alpha to see if the 2.4g issue has been rectified. I’ve had the 2.4g issue since updating to 384.5 and I believe a number of other users have experienced the same. I think I will hang fire until there is a little more feedback.

I've been spending so much time on this...sigh...
So I have backtracked the firmware. I worked my way down from the current merlin release to 380.69_2, and this is the closets firmware to current that I could get all IOT devices working correctly.

Kinda funny, 380.69_2 works with my IOT devices, but Netflix does not work. I need to turn Aiprotection- DNS filtering off for it to work. Or add the device to the no filtering list.

New thought... If it is DNS causing the IOT devices not to work correctly (and it kinda makes sense) I should be able to add all my IOT devices to the non filtered list, and in theory the issue should be gone.
I'll do a full update tomorrow and see if the problem goes away. That makes more sense than a driver issue.
I'll report back.

AC3100 here. I've had nothing but issues with the 384 branch since day 1 (not blaming Merlin at all for this of course, I have no doubt it's an ASUS-related thing). My AC3100 has always ran flawlessly on any of the 380 builds though. With all the 384 builds, everything works fine for about 6 hours, and then everything on either 2.4 or 5 networks slows to an absolute crawl. Restarting fixed the issues, but only for a few hours when it would return again. It was almost as if the router's CPU was under heavy load, but it always showed running at ~10%-20% load. I had tried a variety of things to fix it, but no luck. Rolling back to 380 completely solves this. Hoping I'll see better results with this new .6 release.

 

[kfp]

I had tried a variety of things to fix it, but no luck. Rolling back to 380 completely solves this. Hoping I'll see better results with this new .6 release.

What have you tried? Turned off all the usual suspects like smart connect, airtime fairness, roam assist, beam forming etc?

You said “rolling back” so I assume you never factory reset and reconfigured? Might be worth a try.

I have 3200 running alpha2, uptime is 10+ days now and no hiccups of any kind. No memory leaks either, and this includes an Apple device on the network.

 

[Jon555]

What have you tried? Turned off all the usual suspects like smart connect, airtime fairness, roam assist, beam forming etc?

You said “rolling back” so I assume you never factory reset and reconfigured? Might be worth a try.

I have 3200 running alpha2, uptime is 10+ days now and no hiccups of any kind. No memory leaks either, and this includes an Apple device on the network.

Correct, disabled all the usual suspects (airtime fairness, beam forming, etc.). I always factory reset after any firmware change (regardless of upgrading or downgrading). Thank you for the suggestions though. Very excited to hear this new build is working well for a lot of people, can't wait to try it myself later on.

 

[D_Day]

AC3100 here. I've had nothing but issues with the 384 branch since day 1 (not blaming Merlin at all for this of course, I have no doubt it's an ASUS-related thing). My AC3100 has always ran flawlessly on any of the 380 builds though. With all the 384 builds, everything works fine for about 6 hours, and then everything on either 2.4 or 5 networks slows to an absolute crawl. Restarting fixed the issues, but only for a few hours when it would return again. It was almost as if the router's CPU was under heavy load, but it always showed running at ~10%-20% load. I had tried a variety of things to fix it, but no luck. Rolling back to 380 completely solves this. Hoping I'll see better results with this new .6 release.

I took the plunge and updated to the alpha from 384.5 and had 7 days uptime without any problems before I had to reboot the router, i had to turn off the client in openvpn and I couldn’t get any wan connection to the device until I rebooted. It’s been up for 5 days now without problems again so I’m very pleased.

 

[agilani]

AC3100 here. I've had nothing but issues with the 384 branch since day 1 (not blaming Merlin at all for this of course, I have no doubt it's an ASUS-related thing). My AC3100 has always ran flawlessly on any of the 380 builds though. With all the 384 builds, everything works fine for about 6 hours, and then everything on either 2.4 or 5 networks slows to an absolute crawl. Restarting fixed the issues, but only for a few hours when it would return again. It was almost as if the router's CPU was under heavy load, but it always showed running at ~10%-20% load. I had tried a variety of things to fix it, but no luck. Rolling back to 380 completely solves this. Hoping I'll see better results with this new .6 release.

Try setting the channels manually. It fixed m problems with the 384 code base on my ac3100 and ac88. Stock has the exact same issues. 384.6 is based on 21045 gpl (with some exceptions) which is what the current stock is running.

 

[indark]

AC3100 here. I've had nothing but issues with the 384 branch since day 1 (not blaming Merlin at all for this of course, I have no doubt it's an ASUS-related thing). My AC3100 has always ran flawlessly on any of the 380 builds though. With all the 384 builds, everything works fine for about 6 hours, and then everything on either 2.4 or 5 networks slows to an absolute crawl. Restarting fixed the issues, but only for a few hours when it would return again. It was almost as if the router's CPU was under heavy load, but it always showed running at ~10%-20% load. I had tried a variety of things to fix it, but no luck. Rolling back to 380 completely solves this. Hoping I'll see better results with this new .6 release.

power cycle and clear nvram, and it should fix the CPU load issue.

power off router for 30 sec, hold wps button while power on, wait till power led start blinking/flashing, and release it.
wait till it's properly reboot and you should be good to go.

I always do it when there is major code change (380 -> 384)
or when switch between stock and merlin's firmware.

 

[skeal]

I got nothing! My AC3100 rocks! This latest alpha is awesome, I have had absolutely no problems. This should clear through beta trials in no time. This is probably the best build ever...IMHO. Great work @RMerlin sir!!