What's new

[Release 384/NG] Asuswrt-Merlin 384.3 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

But it should show connection speed for LAN as well, 1000/100/10Mb/s and maybe full/half duplex.
To see if there maybe a connection/cable problem.

The router has no way of knowing this information. That client might be connected through a switch for instance. This is simply technically impossible.
 
Hello guys,

After upgrading my AC88U to this version, some of my lan ports show "RTK" and are non responsive.. The weird problem is that lan4 is free, and it also does a link up but transfers no ARPs at all.. I don't understand what happened, IPTV is working and the LAN1+LAN2 bond for NAS are also working..

Any ideas\logs to troubleshoot? Don't know where to start, but i'm thinking about downgrading..

Thanks

The RTK ports are a separate Realtek switch. Power cycle your router to reset the switch.
 
The RTK ports are a separate Realtek switch. Power cycle your router to reset the switch.
Thanks merlin. How do I power cycle? Do you mean a reboot?
I ended up downgrading to last stable and the problem persisted. I had to reset to factory defaults and the ports were back up.
Please note that restoring factory default in the latest version still has the rtk ports unresponsive..
 
Thanks merlin. How do I power cycle? Do you mean a reboot?

Turn off the power for 5-10 seconds, then turn it back on.
 
I noticed that in the 384.3 firmware, the TX power adjustment is available in the RT-AC1900P but is missing in the RT-AC86U router....

Also the Eco Mode in the asus router app is available in the RT-AC1900P and is missing in the RT-AC86U.

Will this be added to the RT-AC86U in newer firmwares?
 

Attachments

  • AC1900P.jpg
    AC1900P.jpg
    62.6 KB · Views: 475
  • AC86U.jpg
    AC86U.jpg
    59.8 KB · Views: 658
I noticed that in the 384.3 firmware, the TX power adjustment is available in the RT-AC1900P but is missing in the RT-AC86U router....

Also the Eco Mode in the asus router app is available in the RT-AC1900P and is missing in the RT-AC86U.

Will this be added to the RT-AC86U in newer firmwares?

No. Asus only makes that setting available for specific regions (and specific models). This cannot be changed.
 
Just updated from 380.69 to 384.3 and did factory reset.

Not sure if it a bug or not but when I rename a device in Network Map > Client Status, it kicked me out and ask to relogin again. Also, I notice that I lost my internet connection as well. So far that only place that kicked me out when I rename a device
 
When you guys do a factory reset, do you literally re-enter all of your settings and everything? I've set-up static addresses for about 25 IPs, port forwarding, wi-fi, etc. This would take awhile to do each time, no?

Me too. I don't want to have to enter everything manually either. Do let me know please.
 
Just updated from 380.69 to 384.3 and did factory reset.

Not sure if it a bug or not but when I rename a device in Network Map > Client Status, it kicked me out and ask to relogin again. Also, I notice that I lost my internet connection as well. So far that only place that kicked me out when I rename a device

Same issue here on an RT-AC3200, Network Map appears a little flaky. I'm led to understand however that the Network Map components themselves are closed source so not sure if this is anything that @RMerlin can resolve.
 
I have found plenty of info on other threads on this forum and others reporting that there is an issue with the ac68u 384 firmware (ASUS and Merlin) affecting media bridge mode, and repeater mode. The symptoms match my own, so there isn’t a firmware update that will work for me at this time. I’m stable on 380.69_2, and have given up trying to find a solution given this new information. I will be watching for an update. If you use repeater or bridge mode, don’t upgrade. It may have to do with the AiMesh code.

Same here, I've gone back to 380.69_2 as well.
 
I have found plenty of info on other threads on this forum and others reporting that there is an issue with the ac68u 384 firmware (ASUS and Merlin) affecting media bridge mode, and repeater mode. The symptoms match my own, so there isn’t a firmware update that will work for me at this time. I’m stable on 380.69_2, and have given up trying to find a solution given this new information. I will be watching for an update. If you use repeater or bridge mode, don’t upgrade. It may have to do with the AiMesh code.
Same problem here for weeks trying to find a solution.I am sticking with 380.69_2 for the moment.
 
Same issue here on an RT-AC3200, Network Map appears a little flaky. I'm led to understand however that the Network Map components themselves are closed source so not sure if this is anything that @RMerlin can resolve.

This is normal, and the way Asus designed it. They restart the networking stack when you do any change there, to ensure that DHCP leases and such get updated.
 
Yeah I loaded them from a previously saved configuration file. Should I go manually instead?

Sent from my C106 using Tapatalk


By loading from a saved config file; you effectively negated the reset to factory defaults.

Do a reset to factory defaults and them manually setup your router again. This ensures that any bugs you encounter will be based on the new firmware and not with some interaction with old and possibly outdated settings and the firmware you're currently running on.
 
Coming from 382 beta2 -> 384.3, I can confirm that network services filter (blacklist) started working again.

In 382.2 the rules were erroneously marked as "RETURN" in the NFSW chain.
In 384.3 the rules are once again marked as "DROP" in the NSFW chain.

When I noticed the bug, I moved to the "block internet access" feature under network map which created the proper drop rules in the FORWARD chain for my IOT devices.

Glad that both are working properly again. Thanks!@
 
Just recognized that my vpn clients can't connect anymore. I replaced the whole /jffs/openvpn folder with the previous one from the old 380 train (did a factory reset after upgrade), the newly exported ovpn file is identical to the old one but clients stall at tls negotiation
Well, even after resetting and using default vpn server settings and certificates it's not possible for me to connect to my router - still gets stuck at tls negotiation. Anyone else with this problem? Went back to 380 now since I need vpn access.
 
Code:
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x06; Reg_in: 0x08060000; Reg_out: 0x1806ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x07; Reg_in: 0x08070000; Reg_out: 0x1807ffff
27 de fevereiro às 06:25:35 kernel: SIOCGMIIPHY: SwPort inválido: 16
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x00; Reg_in: 0x08000000; Reg_out: 0x1800ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x01; Reg_in: 0x08010000; Reg_out: 0x1801ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x02; Reg_in: 0x08020000; Reg_out: 0x1802ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x03; Reg_in: 0x08030000; Reg_out: 0x1803ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x04; Reg_in: 0x08040000; Reg_out: 0x1804ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x05; Reg_in: 0x08050000; Reg_out: 0x1805ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x06; Reg_in: 0x08060000; Reg_out: 0x1806ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x07; Reg_in: 0x08070000; Reg_out: 0x1807ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x00; Reg_in: 0x08000000; Reg_out: 0x1800ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x01; Reg_in: 0x08010000; Reg_out: 0x1801ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x02; Reg_in: 0x08020000; Reg_out: 0x1802ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x03; Reg_in: 0x08030000; Reg_out: 0x1803ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x04; Reg_in: 0x08040000; Reg_out: 0x1804ffff
27 de fevereiro 06:25:35 kernel: ****** Erro: Acesso MDIO retornado FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x05; Reg_in: 0x08050000; Reg_out: 0x1805ffff
27 de fevereiro às 06:25:35

I have an ac86u. My connection is by pppoe, fiber GPON 100/50.

Restart the router and continue the errors and I am not connected to the internet.

This error only occurs when SNMP is enabled.
 
Last edited:
Could you please advise on what could be wrong with the USB 3.0 in 384.3 on AC68U, it is keep failing in the syslog.log and doesn't make any devices. While USB 2.0 port works just fine.

Try power cycling the router, and a different disk. I can't reproduce the problem on my own RT-AC68U, I was actually doing Samba speed tests recently on it.
 
This error only occurs when SNMP is enabled.

Seems like the snmp daemon is incompatible with that particular model's kernel. I'd have to see if an upgrade could resolve it, otherwise I will have to remove SNMP support for that particular model.

EDIT: net-snmp hasn't been updated since 2012, so not much I can update there.
 
Possible bug: Fixing IP for a device from LAN > DHCP Server is not reflected in Network Map. The client IP type is shown as DHCP until restart. I gave enough time for the Network Map to refresh, but still no luck. Using 384.3 on AC-68U.
 
Possible bug: Fixing IP for a device from LAN > DHCP Server is not reflected in Network Map. The client IP type is shown as DHCP until restart. I gave enough time for the Network Map to refresh, but still no luck. Using 384.3 on AC-68U.
The IP won't reflect the change until the client initiates a request to renew it's lease.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top