Release Asus AC86U New Firmware - 3.0.0.4.386_40451-g30f1b6c

[ATLga]

Ok, so after a few days of mostly problem free uptime on the .386 version, this morning it went wacky. Each morning the log shows the firmware check and always says not needed. This morning noticed some clients dropped, checked the logs and see this crap:

Oct 30 04:56:45 kernel: pgd = ffffffc013832000
Oct 30 04:56:45 kernel: [00000008] *pgd=00000000128b7003, *pud=00000000128b7003, *pmd=00000000128cc003, *pte=0000000000000000
Oct 30 04:56:45 kernel: CPU: 1 PID: 3433 Comm: firmware_check_ Tainted: P O 4.1.27 #2
Oct 30 04:56:45 kernel: Hardware name: Broadcom-v8A (DT)
Oct 30 04:56:45 kernel: task: ffffffc01705d480 ti: ffffffc013b18000 task.ti: ffffffc013b18000
Oct 30 04:56:45 kernel: PC is at 0xf67887e0
Oct 30 04:56:45 kernel: LR is at 0xf6a8b098
Oct 30 04:56:45 kernel: pc : [<00000000f67887e0>] lr : [<00000000f6a8b098>] pstate: 40080010
Oct 30 04:56:45 kernel: sp : 00000000ffcae600
Oct 30 04:56:45 kernel: x12: 00000000f67887a4
Oct 30 04:56:45 kernel: x11: 00000000003272d0 x10: 0000000000334130
Oct 30 04:56:45 kernel: x9 : 00000000f7013000 x8 : 00000000000000f5
Oct 30 04:56:45 kernel: x7 : 00000000003272d0 x6 : 0000000000000001
Oct 30 04:56:45 kernel: x5 : 00000000000000f5 x4 : 0000000000325f30
Oct 30 04:56:45 kernel: x3 : 0000000000000000 x2 : 00000000000000f5
Oct 30 04:56:45 kernel: x1 : 0000000000000001 x0 : 0000000000000000
Oct 30 04:58:17 kernel: pgd = ffffffc014e76000
Oct 30 04:58:17 kernel: [00000008] *pgd=0000000013ba2003, *pud=0000000013ba2003, *pmd=00000000139bc003, *pte=0000000000000000
Oct 30 04:58:17 kernel: CPU: 0 PID: 3885 Comm: firmware_check_ Tainted: P O 4.1.27 #2
Oct 30 04:58:17 kernel: Hardware name: Broadcom-v8A (DT)
Oct 30 04:58:17 kernel: task: ffffffc01716f4c0 ti: ffffffc013b98000 task.ti: ffffffc013b98000
Oct 30 04:58:17 kernel: PC is at 0xf6b897e0
Oct 30 04:58:17 kernel: LR is at 0xf6e8c098

On a whim, I clicked the update button manually and it gave the message could not connect to server then checked the logs and this message was there. So the middle of the night message was there and then again when I clicked update...

NO aiProtect on, no QOS on, NO Trend Micro anything on.

I'm done with .386 for now going back to Aug fw.


Edit: Tried sending feedback from router and got this:

Thanks for taking the time to submit your feedback.

Failed to send your feedback. Please check your Internet connection and try again.

"The system failed to connect to the Feedback server. You can send an email directly to : ( router_feedback@asus.com ) Simply copy the contents below and paste it as your e-mail contents. Or you can bind your Google account to send feedback via e-mail.
Download the following debug files and add them as an email attachment: :"

There is a debug file shown and I'll email that. As far as copying contents below, there was nothing in the box to copy. Lots of BS going on here Asus...

 

[ATLga]

Ok, so after a few days of mostly problem free uptime on the .386 version, this morning it went wacky. Each morning the log shows the firmware check and always says not needed. This morning noticed some clients dropped, checked the logs and see this crap:

Oct 30 04:56:45 kernel: pgd = ffffffc013832000
Oct 30 04:56:45 kernel: [00000008] *pgd=00000000128b7003, *pud=00000000128b7003, *pmd=00000000128cc003, *pte=0000000000000000
Oct 30 04:56:45 kernel: CPU: 1 PID: 3433 Comm: firmware_check_ Tainted: P O 4.1.27 #2
Oct 30 04:56:45 kernel: Hardware name: Broadcom-v8A (DT)
Oct 30 04:56:45 kernel: task: ffffffc01705d480 ti: ffffffc013b18000 task.ti: ffffffc013b18000
Oct 30 04:56:45 kernel: PC is at 0xf67887e0
Oct 30 04:56:45 kernel: LR is at 0xf6a8b098
Oct 30 04:56:45 kernel: pc : [<00000000f67887e0>] lr : [<00000000f6a8b098>] pstate: 40080010
Oct 30 04:56:45 kernel: sp : 00000000ffcae600
Oct 30 04:56:45 kernel: x12: 00000000f67887a4
Oct 30 04:56:45 kernel: x11: 00000000003272d0 x10: 0000000000334130
Oct 30 04:56:45 kernel: x9 : 00000000f7013000 x8 : 00000000000000f5
Oct 30 04:56:45 kernel: x7 : 00000000003272d0 x6 : 0000000000000001
Oct 30 04:56:45 kernel: x5 : 00000000000000f5 x4 : 0000000000325f30
Oct 30 04:56:45 kernel: x3 : 0000000000000000 x2 : 00000000000000f5
Oct 30 04:56:45 kernel: x1 : 0000000000000001 x0 : 0000000000000000
Oct 30 04:58:17 kernel: pgd = ffffffc014e76000
Oct 30 04:58:17 kernel: [00000008] *pgd=0000000013ba2003, *pud=0000000013ba2003, *pmd=00000000139bc003, *pte=0000000000000000
Oct 30 04:58:17 kernel: CPU: 0 PID: 3885 Comm: firmware_check_ Tainted: P O 4.1.27 #2
Oct 30 04:58:17 kernel: Hardware name: Broadcom-v8A (DT)
Oct 30 04:58:17 kernel: task: ffffffc01716f4c0 ti: ffffffc013b98000 task.ti: ffffffc013b98000
Oct 30 04:58:17 kernel: PC is at 0xf6b897e0
Oct 30 04:58:17 kernel: LR is at 0xf6e8c098

On a whim, I clicked the update button manually and it gave the message could not connect to server then checked the logs and this message was there. So the middle of the night message was there and then again when I clicked update...

NO aiProtect on, no QOS on, NO Trend Micro anything on.

I'm done with .386 for now going back to Aug fw.


Edit: Tried sending feedback from router and got this:

Thanks for taking the time to submit your feedback.

Failed to send your feedback. Please check your Internet connection and try again.

"The system failed to connect to the Feedback server. You can send an email directly to : ( router_feedback@asus.com ) Simply copy the contents below and paste it as your e-mail contents. Or you can bind your Google account to send feedback via e-mail.
Download the following debug files and add them as an email attachment: :"

There is a debug file shown and I'll email that. As far as copying contents below, there was nothing in the box to copy. Lots of BS going on here Asus...

Well it gets better, couldn't send the file to them via email. It's a file type that's blocked. I'll send an email without the attachment.

Rolled back to .384 Aug fw and the update check went through immediately no error, although it said .386 fw available hahaha. Skipping it this time.

It is a little strange that I've had many days of uptime and each night the firmware checker has not given this tainted error. It appears to be Broadcom related since it's mentioned in there but that could just be the coding. Or it could be related to the Asus site rearranging going on with the links etc. However, it worked fine on .384 so I'm just not sure and guessing. Regardless, I'm on .384 again and will sit on this. This is the kind of crap you get when your firmware (.386) is still in beta and you start releasing parts of it to production that you think are good. Just release it once it's done and fully tested.

 

[OzarkEdge]

Well it gets better, couldn't send the file to them via email. It's a file type that's blocked. I'll send an email without the attachment.

Rolled back to .384 Aug fw and the update check went through immediately no error, although it said .386 fw available hahaha. Skipping it this time.

It is a little strange that I've had many days of uptime and each night the firmware checker has not given this tainted error. It appears to be Broadcom related since it's mentioned in there but that could just be the coding. Or it could be related to the Asus site rearranging going on with the links etc. However, it worked fine on .384 so I'm just not sure and guessing. Regardless, I'm on .384 again and will sit on this. This is the kind of crap you get when your firmware (.386) is still in beta and you start releasing parts of it to production that you think are good. Just release it once it's done and fully tested.

Besides those log entries, was the router still working for you?

OE

 

[brentil]

Just an FYI the new 386 firmware guest networks now use their own Class C IP spaces. Where previous behavior was everything in say 192.168.1 you now have;

• Main IP space 192.168.1
• GN1 192.168.101
• GN2 192.168.102
• GN3 192.168.103

I like this new change BUT you can no longer assign DHCP static leases for these GN ranges. So if you had manual assignments for items on those guest networks it will ignore them and start assigning random IPs in those spaces.

Anyone know where we can submit official feature regression bugs to Asus about this?

 

[XIII]

Just an FYI the new 386 firmware guest networks now use their own Class C IP spaces.

I like this new change BUT you can no longer assign DHCP static leases for these GN ranges

Wow, that sucks (I use guest networks for my IoT devices).

Would @RMerlin be able to do that differently on his firmware?

 

[OzarkEdge]

Anyone know where we can submit official feature regression bugs to Asus about this?

I'm suspect they know this already.

OE

 

[RMerlin]

Would @RMerlin be able to do that differently on his firmware?

I don't do that type of architectural changes. But I might look at possibly allowing static DHCP leases to be configured on the webui. Otherwise, users will also be able to do it through a dnsmasq.add conf file.

 

[dave14305]

I don't do that type of architectural changes. But I might look at possibly allowing static DHCP leases to be configured on the webui. Otherwise, users will also be able to do it through a dnsmasq.add conf file.

For the sake of discussion, would there be a way to differentiate a client that switches between guest and non-guest SSIDs since the MAC could be the same (ignoring iOS 14 Private MACs for now)? I think there would be a risk of giving a client a reservation in the wrong subnet if they are already allowed to switch between SSIDs. Maybe not a typical use-case for guest networks, but I would be concerned it could get messy.

 

[bbunge]

Well it gets better, couldn't send the file to them via email. It's a file type that's blocked. I'll send an email without the attachment.

Rolled back to .384 Aug fw and the update check went through immediately no error, although it said .386 fw available hahaha. Skipping it this time.

It is a little strange that I've had many days of uptime and each night the firmware checker has not given this tainted error. It appears to be Broadcom related since it's mentioned in there but that could just be the coding. Or it could be related to the Asus site rearranging going on with the links etc. However, it worked fine on .384 so I'm just not sure and guessing. Regardless, I'm on .384 again and will sit on this. This is the kind of crap you get when your firmware (.386) is still in beta and you start releasing parts of it to production that you think are good. Just release it once it's done and fully tested.

I see those same log entries. I do not consider them as errors. If they concern you just don't look at the log. My AC86U is working well on the Current Version : 3.0.0.4.386_40451-g30f1b6c firmware.

 

[RMerlin]

For the sake of discussion, would there be a way to differentiate a client that switches between guest and non-guest SSIDs since the MAC could be the same (ignoring iOS 14 Private MACs for now)?

I doubt it, but then I haven't studied the new implementation yet, since it was still very early code, so I was expecting things to change throughout the beta cycle. So, I don't know how isolated the two subnets are, whether they have separate DHCP scopes, etc...

Having received the RC2-7 GPL code yesterday, my focus right now is strictly on merging things (and adding all the models previously missing from my RC2-1 merge). Too early yet for me to start analyzing the 386 changes in depth, or making plans for future changes.

 

[ATLga]

Besides those log entries, was the router still working for you?

OE

Yes, other than what I had already mentioned in my previous posts nothing to report other than new Kernel issues that materialized this morning.

 

[ATLga]

I see those same log entries. I do not consider them as errors. If they concern you just don't look at the log. My AC86U is working well on the Current Version : 3.0.0.4.386_40451-g30f1b6c firmware.

Yeah that's the way to do it. Just ignore it and then it doesn't exist. Hahaha.

 

[tcb_38]

Did someone loose wake on lan feature with new firmware?
I use WOL on my AC86U to wake up a server.Can't do it anymore after upgrade.
Thanks

 

[aurora]

Over months in different versions of both Asus or Merlin FW versions, the WOL can fail when RAM usage is in the 80%+ range. Power cycling the router solve the problem, but it will come back again and again when RAM usage slowly moved up to >80%. Typically it happened after >83-85% RAM usage.

 

[bitsbytes]

Over months in different versions of both Asus or Merlin FW versions, the WOL can fail when RAM usage is in the 80%+ range. Power cycling the router solve the problem, but it will come back again and again when RAM usage slowly moved up to >80%. Typically it happened after >83-85% RAM usage.

i always hit 80-90% after a week or more of uptime without any issues at all. I never had this issue with this firmware or any previous firmware.

 

[aurora]

Do you use WOL function via the router UI? I am referring specifically to this.
Also, when the RAM usage inching up to high 80%, I did encountered the router UI cannot be accessed. However, the router still doing the usual jobs, if not logging into router UI I won't know UI issue. Power cycle the router also solve the problem.
FYI, this also happened to my RT-AC68U as a router. I changed/upgraded to RT-AC86U some months ago.

 

[tcb_38]

After last update is the first time I can not use WOL. Ram usage was almost %100. So,I definitely believe RAM have nothing to do with WOL.
BTW,what make RAM be so high?

 

[aurora]

If power cycle router does not solve your problem, then you may want to do a factory reset via the UI and configure everything from beginning.
I did this when I faced issues in the past.

So far after doing dirty update I do not see any issue yet. I only did a power cycle after installing the latest FW.

 

[programatix]

I found an issue with the Network Printer Server. If I turn off my printer, and then later turn it on again, all clients will be unable to print via LPR. To get it to work again, I either need to restart the router or disable Network Printer Server and re-enable it again in the webui. The problem will come back every time I turn off the printer or when the printer turn itself off.

Problem may be caused by,

7. Printer server port can be disabled on the USB app page.

I reverted back to 3.0.0.4.384.82072 and the problem goes away.

 

[128bit]

well, i haven't dropped back yet but as brentil mentioned, something's up with the guest network on MY 2.4g radio. i highlight "my" cause it's the 2.4 radio and i've not completed problem determination; not sure of other folks experiences.
what i can say is that my guest clients all ihave a 192.168.. addy now which is odd, since the network/86u domain is completely different! what's weird is that some may have worked for awhile!! keyward their is "may" ok. my ecobee thermostats are on the guest network and they've been fine with access via the ecobee server as well. no more, though. both are broke now even when off guest. while they connect to my intranet, they won't connect to the ecobee server. this may indicate yet another problem but again, still doing tests.
all other clients wired and radioed work fine. so something's weird here but i'm leaning towards an asus bug. may have to revert but more pd first.

so why the lean, you ask. we had a power outage a few nights ago and my whole house gen kicked in. specturm/tw typically runs ok when we lose power but not that night. when everything came back, that's when i noticed the 192... ips in my client list. sure, it could've been there before - can't tell though. did all the full resets (3x) and manual re-entries but no change. i can tell u that the generator will test your surge protectors, k. every time a hvac unit comes on, the motor bogs down, then revs up to handle the load. you can see led lights flicker when that happens. that's a surge, people. i'm just hoping this is not a damaged 86u, just a bad build. i will revert soon but look forward to comments.