384.3 Random Errors

[muffintastic]

Hi,

I have an ASUS RT-AC3200 - I've kind of touched on this subject since upgrading but now this is getting a bit out of hand.

"These Errors" seem to be off and on and sometimes never occur but they're occuring a lot, either from a power cycle - nvram reset via SSH - and a FW restore via the Asus Recovery Utility. I never had this isssue from the previous branch and I wonder if @RMerlin could shed some light or someone else.

Before you reply..

1. Before moving from the old branch of 380.xxx I made sure NVRAM was correctly cleared and factory defaulted with the many guides available.
2. I have used the Asus Firmware Restore Utility to upload the 384.3 file.
3. I have then proceeded to do another power cycle / NVRAM reset via SSH and then via GUI.
4. I have the router sitting to an external modem and my ISP is Sky Fibre UK
5. I am running a brand new Ethernet cable from the router to modem, so I know it's not a connectivity issue.

Feb 28 10:04:27 rc_service: httpd 308:notify_rc restart_wan_if 0
Feb 28 10:04:27 wan: [deconfig] udhcpc done[286]
Feb 28 10:04:27 miniupnpd[1050]: Failed to get IP for interface eth0
Feb 28 10:04:27 miniupnpd[1050]: SendNATPMPPublicAddressChangeNotification: cannot
Feb 28 10:04:30 kernel: ADDRCONF(NETDEV_UP): ifb0: link is not ready
Feb 28 10:04:30 kernel: ADDRCONF(NETDEV_UP): ifb1: link is not ready
Feb 28 10:04:32 wan: finish adding multi routes
Feb 28 10:04:32 miniupnpd[1050]: shutting down MiniUPnPd
Feb 28 10:04:33 rc_service: udhcpc 2412:notify_rc stop_upnp
Feb 28 10:04:33 rc_service: waitting "start_firewall" via udhcpc ...
Feb 28 10:04:33 kernel: registering ipv6 ROUTE target
Feb 28 10:04:33 nat: apply nat rules (/tmp/nat_rules_eth0_eth0) error!
Feb 28 10:04:54 nat: apply nat rules (/tmp/nat_rules_eth0_eth0) error!

In the old code base of 380.xxx or when I was running 380.69_2 this ran fine, my CPU model if revelant is: CPU Model ARMv7 Processor rev 0 (v7l) (Cores: 2)

 

[RMerlin]

Try 384.4 Beta, which is based on a newer Asus GPL release. Also try disconnecting the power from your modem for 10-15 mins to reset the connection with your ISP.

 

[muffintastic]

Try 384.4 Beta, which is based on a newer Asus GPL release. Also try disconnecting the power from your modem for 10-15 mins to reset the connection with your ISP.

I did try 384.4 but I'm getting constant CPU utilization on both cores for some strange reason. I will try your method and will report with my results.

 

[Striker317]

Hi,

I have an ASUS RT-AC3200 - I've kind of touched on this subject since upgrading but now this is getting a bit out of hand.

"These Errors" seem to be off and on and sometimes never occur but they're occuring a lot, either from a power cycle - nvram reset via SSH - and a FW restore via the Asus Recovery Utility. I never had this isssue from the previous branch and I wonder if @RMerlin could shed some light or someone else.

Before you reply..

1. Before moving from the old branch of 380.xxx I made sure NVRAM was correctly cleared and factory defaulted with the many guides available.
2. I have used the Asus Firmware Restore Utility to upload the 384.3 file.
3. I have then proceeded to do another power cycle / NVRAM reset via SSH and then via GUI.
4. I have the router sitting to an external modem and my ISP is Sky Fibre UK
5. I am running a brand new Ethernet cable from the router to modem, so I know it's not a connectivity issue.

Feb 28 10:04:27 rc_service: httpd 308:notify_rc restart_wan_if 0
Feb 28 10:04:27 wan: [deconfig] udhcpc done[286]
Feb 28 10:04:27 miniupnpd[1050]: Failed to get IP for interface eth0
Feb 28 10:04:27 miniupnpd[1050]: SendNATPMPPublicAddressChangeNotification: cannot
Feb 28 10:04:30 kernel: ADDRCONF(NETDEV_UP): ifb0: link is not ready
Feb 28 10:04:30 kernel: ADDRCONF(NETDEV_UP): ifb1: link is not ready
Feb 28 10:04:32 wan: finish adding multi routes
Feb 28 10:04:32 miniupnpd[1050]: shutting down MiniUPnPd
Feb 28 10:04:33 rc_service: udhcpc 2412:notify_rc stop_upnp
Feb 28 10:04:33 rc_service: waitting "start_firewall" via udhcpc ...
Feb 28 10:04:33 kernel: registering ipv6 ROUTE target
Feb 28 10:04:33 nat: apply nat rules (/tmp/nat_rules_eth0_eth0) error!
Feb 28 10:04:54 nat: apply nat rules (/tmp/nat_rules_eth0_eth0) error!

In the old code base of 380.xxx or when I was running 380.69_2 this ran fine, my CPU model if revelant is: CPU Model ARMv7 Processor rev 0 (v7l) (Cores: 2)

Do you have another Ethernet cable that you can swap in to test. It is something that changed (being brand new is not a 100% guarantee that it will work right).

 

[muffintastic]

Do you have another Ethernet cable that you can swap in to test. It is something that changed (being brand new is not a 100% guarantee that it will work right).

I have a lot of them and yes I've tried them all. It seems to work for a few days then stops working, with the current errors in the code area in my post. I can assure you in branch 380.xxx it was working fine and gurantee you it wasn't an Ethernet cable, so if I haven't changed anything hardware wise it's quite clearly a software issue. I can only tell you that branch 380.xxx worked flawlessly but since upgrading I've had those errors plus more. So why would it be a hardware issue if I've change nothing?

 

[Dave K]

384.4 is pooched too. It was stable until I tried to enable WPS.. wifi died and didnt return. flashing Stock FW_RT_AC3200_300438250010..

 

[RMerlin]

I did try 384.4 but I'm getting constant CPU utilization on both cores for some strange reason. I will try your method and will report with my results.

You'd have to run "top" over SSH to determine what is using the CPU. A common cause is if you have a USB disk plugged in, then the media server might be scanning its content to build the DLNA database.

 

[RMerlin]

384.4 is pooched too. It was stable until I tried to enable WPS.. wifi died and didnt return. flashing Stock FW_RT_AC3200_300438250010..

I just disabled then re-enabled WPS on my RT-AC3200 without any issue. You mean enabled by the webui?

 

[muffintastic]

I just disabled then re-enabled WPS on my RT-AC3200 without any issue. You mean enabled by the webui?

Re-enabling then disabling the WPS has fixed this 1 issue. Re-garding my earlier errors what would be the cause regarding this NAT issue / miniupnpd, is a kernel problem or software that makes the magic that happens bugged?

Again, I can't stress this enough I have done extensive testing with my ISP router and this works fine for hours as stated with different Ethernet cables, it's only happend ever since jumping ship to the 384.xxx branch of code this has started to fumble @RMerlin .

 

[ColinTaylor]

You talk about "these errors" as if you have multiple separate problems. From the short section of syslog you posted I can only see 1 problem, that being your WAN connection (eth0) is not functioning. The following messages about miniupnpd, nat, etc. are just a consequence of the original fault.

 

[Dave K]

You talk about "these errors" as if you have multiple separate problems. From the short section of syslog you posted I can only see 1 problem, that being your WAN connection (eth0) is not functioning. The following messages about miniupnpd, nat, etc. are just a consequence of the original fault.

Merlin: yes through WEBUI.. any time I would change any settings for the Wireless the CPU would go crazy and would have to reboot to see the changes apply. and from the time it said saving settings to reboot the radios would turn off. (still on in the ui, but my laptop running inssider couldnt see it)

Colin: there are other threads about issues with the AC3200 running 384.3+

I'm not using any of the ASUS features at all. I have a NAS with a VPN server. All the Asus AI cloud, QOS, aiprotection is all disabled. No USB.
I have flashed this with every merlin update for the last 2-3 years with no issue. until now.

Running stock 3.0.0.4.382_50010 I havent seen any issues thus far.

 

[muffintastic]

You talk about "these errors" as if you have multiple separate problems. From the short section of syslog you posted I can only see 1 problem, that being your WAN connection (eth0) is not functioning. The following messages about miniupnpd, nat, etc. are just a consequence of the original fault.

Read my posts please. I'll explain again WAN connection etc works fine on the ISP provided router, if you read sine UPGRADING TO BRANCH 384.XXX I'VE STARTED TO ENCOUNTER THESE ERRORS why would you assume it's my ISP or MY FAULT? What don't you understand from my replies don't you get? BRANCH 380.XXX WORKED FINE, UPGRADING TO 384.XXX I'VE HAD NOTHING BUT ISSSUES. *bangs head againsts wall*

 

[Odkrys]

When you report bug to merlin, check the bug with stock firmware.
If the bug still exist on stock firmware then it's not specific problem of merlin firmware.
Report it to ASUS too.

 

[muffintastic]

When you report bug to merlin, check the bug with stock firmware.
If the bug still exist on stock firmware then it's not specific problem of merlin firmware.
Report it to ASUS too.

I am unable to try the "official" FW since my ISP (Sky UK) uses a weird authentication mechanism, MER (OPTION 61) which doesn't give me the option to clone my original ISPs router MAC address but Merlin's does so that is out of the question. I know someone on this forum knows what my problem is and understands my problem which I'm not going to explain again.

@RMerlin I had that NAT Error popup in my logs again this morning so which causes port forwarding to break etc - I'm stumped I can't see how upgrading from 380.xxx > 384.xxx breaks the router, it's a shame I can't roll back to a previous build when It worked but I guess I'll have to keep switching the router off for it to reset and work again.

 

[ColinTaylor]

Read my posts please. I'll explain again WAN connection etc works fine on the ISP provided router, if you read sine UPGRADING TO BRANCH 384.XXX I'VE STARTED TO ENCOUNTER THESE ERRORS why would you assume it's my ISP or MY FAULT? What don't you understand from my replies don't you get? BRANCH 380.XXX WORKED FINE, UPGRADING TO 384.XXX I'VE HAD NOTHING BUT ISSSUES. *bangs head againsts wall*

There's no need to shout. Yes I did read your post. Yes I did understand your replies.

I'm not denying you have a problem. I was just pointing out your OP demonstrates 1 issue. You then go on to ask what is the cause of the NAT/miniupnpd messages as if they themselves demonstrated separate issues. Perhaps I misinterpreted that. I was trying to point out that the NAT/miniupnpd messages in themselves do not indicate separate issues. They are just a consequence on eth0 not working. Fix eth0 and the NAT/miniupnpd errors will go away.

 

[RMerlin]

I can't reproduce the problem on my own RT-AC3200 running 384.4 beta. I kept it running for about about 10 hours without a single issue.

 

[muffintastic]

I'm completely stumped ran out of ideas to be honest...

 

[WillNonya]

I tried to follow this thread because i have the 3200 with 384.3 but as soon as op said they were running this firmware and turning on WPS I figured there's no point...

 

[Dave K]

I tried to follow this thread because i have the 3200 with 384.3 but as soon as op said they were running this firmware and turning on WPS I figured there's no point...

I have a printer which for some reason cannot connect to the wifi.. I figured I would give WPS a go.. no dice so i ended up turning off WPS and running an ethernet cable
BTW I have had 0 luck cracking WPS with KALI.. almost all modern routers have brute force prevention in place. And pixie no longer works on patched devices either.

but thanks for the snide trolling remarks.. you are very helpful.

In fact whenever someone seems to question the integrity of a release around here there is a rash of shirtty replies such as the above (there are a few of you out there that try earnestly to help.. thank you)

PS I wasnt the OP.. try reading..

 

[Jack Yaz]

I have a printer which for some reason cannot connect to the wifi.. I figured I would give WPS a go.. no dice so i ended up turning off WPS and running an ethernet cable
BTW I have had 0 luck cracking WPS with KALI.. almost all modern routers have brute force prevention in place. And pixie no longer works on patched devices either.

but thanks for the snide trolling remarks.. you are very helpful.

In fact whenever someone seems to question the integrity of a release around here there is a rash of shirtty replies such as the above (there are a few of you out there that try earnestly to help.. thank you)

PS I wasnt the OP.. try reading..

Barb-trading aside....airtime fairness (if enabled) can cause problems with printers connecting to WiFi. So if it's enabled, try disabling it. It can be found under the Professional tab of the Wireless section.