ASUS RT-AC68U Firmware version 3.0.0.4.384.81049

[RMerlin]

SMB NOT WORKING with WINDOWS 10 V1809
SMB worked on my windows 10 machine set to SMB1 on built 45717

With the new built set on SMB2 only windows 10 doesn't see the drive at all!

With the SMB1 settings on windows 10 which worked on built 45717 I can see the drive.
However when trying to access the drive I get the following message:
View attachment 19272

Am I the only one, or can you guys access your Samba Share drive after the new update in Windows 10?
I am sharing my samba on my local drive with guest login - ENABLED.

Reboot your computer to ensure it renegotiate the protocol to use - Windows cannot automatically handle changes in supported protocols from the server side.

 

[bachastain]

2 RT-AC66U B1 running 81049. 1 router and 1 mesh node.

I got a lot of the Auth/Assoc/Deauth/Disassoc log entries after loading 81049 on both boxes. However, it seems to be slowing. Only about 2-6 per hour now.

Other than that, seems to be running smoothly.

 

[SomeWhereOverTheRainBow]

One of my rtac68 nodes continuously becomes unpaired with aimesh overtime with this firmware update. I noticed it is one of the earlier rev. Rtac68. I wonder if that could be a factor.

Yep I am reverting back to older firmware I have noticed a flaw with using this on RT-AC68 while it is acting as a node, let it be known the issue happens only on an older rev. RT-AC68. I did not notice an issue with the newer rev. I have.

 

[bachastain]

2 RT-AC66U B1s. 1 router and 1 mesh node. Router was not reset when 81049 was installed, but the mesh node was reset and re-added. My test client is a PC with a PCE-AC88 . I was running a ping tester against the router, the mesh node, and an external internet address.

At 8:34 am today the ping tester reported all pings failing after running error free for almost a full day. This was due to all clients currently attached to the mesh node were forcibly detached. The clients then flipped back to the router, leaving exactly 0 attached to the mesh node.

This is an extract from the mesh node log (not the router log):

Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 08:34:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 01:10:00:00:00:00, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 7 08:34:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl1.1: Deauth_ind 2C:FD:A1:CD:C4:E7, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 7 08:35:57 rc_service: amas_wlcconnect 287:notify_rc restart_wireless
Sep 7 08:36:01 rc_service: watchdog 260:notify_rc start_amas_bhctrl
Sep 7 08:36:01 rc_service: waitting "restart_wireless" via ...
Sep 7 08:36:01 kernel: dpsta enabled, uif_bmap 0x3
Sep 7 08:36:02 acsd: scan in progress ...
Sep 7 08:36:02 acsd: scan in progress ...
Sep 7 08:36:02 acsd: scan in progress ...

2C:FD:A1:CD:C4:E7 is my PCE-AC88 client. After the 3 clients attached to the node all flipped over to the router, pings were restored at 8:36 am.

This is pretty close to the same symptom I was getting on previous releases. The log entries are a bit different but clients on the node being forced to randomly disconnect is not. The mesh node runs fine for up to 48 hours and then randomly blows off all the clients.

I happen to have a 3rd spare RT-AC66U B1 and in the past have tried swapping the boxes around in different combinations with zero impact on the disconnects. Also note the disconnects never happen when I run router only. By itself the router is flawlessly reliable. The disconnects only happen to clients attached to the mesh node.

The node and router are only about 25-30 feet apart (a couple of walls) and everything shows strong signals. My test client is only about 20 feet from the mesh node and also shows a strong signal.

So the result is the same. The ASUS mesh setup still remains unusable almost exactly 1 year after I bought the boxes hoping to fix a dead spot in the basement with a mesh.

Update: Both 2.4 and 5 are using fixed channels with separate SSIDs.

 

[sdmf74]

Dunno why it took them so long, especially since they could have just lifted the necessary code from me.

They ended up doing it from the ground up on their own - at least they also used the same starting point as me (the OpenWRT port). Now I will have to harmonize our two distinct implementations.

Figures, well at least im sure they have a different development team writing software for their routers than they do with their motherboards because its a disaster, especially when it comes to them fixing a bug

 

[netmann]

I could not use the the web GUI on my PC so I used Asus iPhone app to update to 81049 on my 68U. It went smoothly but after the router power cycle I still cannot access the GUI with PC either thru the router's IP address or via router.asus.com ?!

 

[sdmf74]

Are you still using 81039 on the main router? cause that was the issue & why they pulled that firmware.

@Merlin Is it necessary to do a reboot or factory reset at/on the node if only flashing the node & not the main router?

 

[heysoundude]

this is, as someone noted in another thread, a fairly sizeable jump from the last stable firmware; it wouldn't be a bad idea to factory reset rather than just the power cycle asus recommends after DL/install.

Note that RMerlin has been ahead of asus devs with his firmware for a while - and that doesn't take into account any of the adblocking/firewall etc scripts that community's members have written/built/tweaked.

if the stock FW having issues (and them not getting resolved in as timely a manner you would expect from a large wealthy corp) is bugging you, you should seriously consider making the switch.
If you don't believe me, try FreshJR's QoS implementation (I seem to recall it works on stock asus firmware) - that's just a basic example of how a bit of informed tweaking can make your router hardware be better at its job.

 

[sdmf74]

Yeah Merlin firmware is great. Dont you have to use SSH to use FreshJR QOS though? Ive never used any SSH script before. In this case I suppose it would only be a matter of copy & paste. Ill look into it although bufferbloat is not really an issue for me anymore

 

[OzarkEdge]

2 RT-AC66U B1s. 1 router and 1 mesh node. Router was not reset when 81049 was installed, but the mesh node was reset and re-added. My test client is a PC with a PCE-AC88 . I was running a ping tester against the router, the mesh node, and an external internet address.

At 8:34 am today the ping tester reported all pings failing after running error free for almost a full day. This was due to all clients currently attached to the mesh node were forcibly detached. The clients then flipped back to the router, leaving exactly 0 attached to the mesh node.

This is an extract from the mesh node log (not the router log):

Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 08:34:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 01:10:00:00:00:00, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 7 08:34:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl1.1: Deauth_ind 2C:FD:A1:CD:C4:E7, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 7 08:35:57 rc_service: amas_wlcconnect 287:notify_rc restart_wireless
Sep 7 08:36:01 rc_service: watchdog 260:notify_rc start_amas_bhctrl
Sep 7 08:36:01 rc_service: waitting "restart_wireless" via ...
Sep 7 08:36:01 kernel: dpsta enabled, uif_bmap 0x3
Sep 7 08:36:02 acsd: scan in progress ...
Sep 7 08:36:02 acsd: scan in progress ...
Sep 7 08:36:02 acsd: scan in progress ...

2C:FD:A1:CD:C4:E7 is my PCE-AC88 client. After the 3 clients attached to the node all flipped over to the router, pings were restored at 8:36 am.

This is pretty close to the same symptom I was getting on previous releases. The log entries are a bit different but clients on the node being forced to randomly disconnect is not. The mesh node runs fine for up to 48 hours and then randomly blows off all the clients.

I happen to have a 3rd spare RT-AC66U B1 and in the past have tried swapping the boxes around in different combinations with zero impact on the disconnects. Also note the disconnects never happen when I run router only. By itself the router is flawlessly reliable. The disconnects only happen to clients attached to the mesh node.

The node and router are only about 25-30 feet apart (a couple of walls) and everything shows strong signals. My test client is only about 20 feet from the mesh node and also shows a strong signal.

So the result is the same. The ASUS mesh setup still remains unusable almost exactly 1 year after I bought the boxes hoping to fix a dead spot in the basement with a mesh.

Update: Both 2.4 and 5 are using fixed channels with separate SSIDs.

Roughly what is the signal power for router and node bands halfway between them? A WiFi Analyzer app can tell you this.

Are you going to reset the router (and node) and re-configure your network/AiMesh, or leave it as it is?

Are you running any Trend Micro features?

Have you tried using each router as a standalone router for a time to see if any one reveals an intermittent fault?

OE

 

[bachastain]

Roughly what is the signal power for router and node bands halfway between them? A WiFi Analyzer app can tell you this.

Are you going to reset the router (and node) and re-configure your network/AiMesh, or leave it as it is?

Are you running any Trend Micro features?

Have you tried using each router as a standalone router for a time to see if any one reveals an intermittent fault?

OE

If it was just 2.4 I wouldn't need the mesh at all. But these thick cabin walls play hell on the 5 band. The 5 drops way off in the corner of the basement and connections often fail and are very intermittent. The router is at one end of the 1st floor and the node is mid floor in the basement, separated by about 4 layers of thick wood. From about middle it's -64 dBm to the router and -51 dBm to the node.

I can't afford the router downtime at the moment. I do plan on resetting the router if these symptoms continue. I've done it several times over the last year and it never made a difference.

Yes. All Trend Micro features are enabled.

Yes, all 3 boxes have been tested for weeks in a sole router mode. Performance is great (except for the dead spot in the basement) and identical.

Mid day today the router started logging these lines every couple of seconds for over an hour:

Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 18:31:BF:E141, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 18:31:BF:E141, status: 0, reason: d11 RC reserved (0)
Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 18:31:BF:E141, status: 0, reason: d11 RC reserved (0)

18:31:BF:E141 is the node so something between the router and node got hosed. I did a telnet reboot on the node which fixed it. It's quiet again.

BTW, Roaming Assistant is off. It caused attach thrashing on a couple of Android phones so I had to disable it. I played with the dBm a few times, but could never get to help roaming without causing more problems than it fixed.

 

[RMerlin]

Are you still using 81039 on the main router? cause that was the issue & why they pulled that firmware.

@Merlin Is it necessary to do a reboot or factory reset at/on the node if only flashing the node & not the main router?

No idea, I don't use AiMesh. Can't hurt to try resetting the nodes anyway, since it doesn't require much work to readd to your network - no need to reconfigure everything manually.

Note that RMerlin has been ahead of asus devs with his firmware for a while

I wouldn't say I'm ahead. A large number of bug fixing is done by them, so they won't find their way into my firmware until they release the source code, and I've had time to merge it in. There are just a few very specific aspects were I might be ahead of them (more timely integration of OpenSSL or kernel security patches, for example).

People should consider my firmware and theirs as two parallel development branches, where one can get ahead of the other, then it's the other way around for a while.

 

[VANT]

If it was just 2.4 I wouldn't need the mesh at all. But these thick cabin walls play hell on the 5 band. The 5 drops way off in the corner of the basement and connections often fail and are very intermittent. The router is at one end of the 1st floor and the node is mid floor in the basement, separated by about 4 layers of thick wood. From about middle it's -64 dBm to the router and -51 dBm to the node.

I can't afford the router downtime at the moment. I do plan on resetting the router if these symptoms continue. I've done it several times over the last year and it never made a difference.

Yes. All Trend Micro features are enabled.

Yes, all 3 boxes have been tested for weeks in a sole router mode. Performance is great (except for the dead spot in the basement) and identical.

Mid day today the router started logging these lines every couple of seconds for over an hour:

Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 18:31:BF:E141, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 18:31:BF:E141, status: 0, reason: d11 RC reserved (0)
Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 18:31:BF:E141, status: 0, reason: d11 RC reserved (0)

18:31:BF:E141 is the node so something between the router and node got hosed. I did a telnet reboot on the node which fixed it. It's quiet again.

BTW, Roaming Assistant is off. It caused attach thrashing on a couple of Android phones so I had to disable it. I played with the dBm a few times, but could never get to help roaming without causing more problems than it fixed.

same in my AIMesh system. My RSSI for node is -66 to -51dBm. When WLCEVENTD is started for node, then i lose 2.4GHz on node, only 5GHz is accessable.
in wifi log i see that node is not authorized

Stations List                         
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
    2C:xx:A1:xx:69:xx Yes                      0dBm ac  No  Yes Yes  No     3      1M         00:00:08

I try factory default and readd node, help for some times, My AIMesh router is jump from 81039 (AIMesh on this fw was very stable) without factory default. I will try factory default for 86u and we will see. If not help i back to 81039.

btw. anyone have this fw ?

 

[Starbuck99]

Reboot your computer to ensure it renegotiate the protocol to use - Windows cannot automatically handle changes in supported protocols from the server side.

Had to re-install windows 10.
After that had to enable SMB1 - Native SMB 2 windows 10 doesn't see the SMB drive.
However, it works now the same as before. Not sure why I had to re-install windows, since the settings basically stayed the same. Windows 10 - SMB1 activated.

 

[OzarkEdge]

btw. anyone have this fw ?

I have FW_RT_AC86U_300438481039_v2, not 68U.

OE

 

[OzarkEdge]

Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 18:31:BF:E141, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 18:31:BF:E141, status: 0, reason: d11 RC reserved (0)
Sep 7 12:53:34 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 18:31:BF:E141, status: 0, reason: d11 RC reserved (0)

18:31:BF:E141 is the node so something between the router and node got hosed. I did a telnet reboot on the node which fixed it. It's quiet again.

eth1 suggests those log entries are for a wired LAN client(?). Is your node wired? Are you sure that is a node MAC? I'm not sure what the ethn assignments are on the 66U B1.

OE

 

[Eric Lieb]

Did ASUS already pull this firmware? Wondering if I should revert. Noticing random drops on my devices (have to restart a device for it to get internet again).

Starting to wonder if my AC68u router (and/or my mesh node) is the problem and it is time to upgrade to something better.

 

[OzarkEdge]

Did ASUS already pull this firmware? Wondering if I should revert. Noticing random drops on my devices (have to restart a device for it to get internet again).

Starting to wonder if my AC68u router (and/or my mesh node) is the problem and it is time to upgrade to something better.

There are some observations trickling in that suggest 81049 is being pulled. If you have issues, reverting to 45717 might be the next step.

OE

 

[bachastain]

eth1 suggests those log entries are for a wired LAN client(?). Is your node wired? Are you sure that is a node MAC? I'm not sure what the ethn assignments are on the 66U B1.

OE

None of the Ethernet ports on either box are used. Only the WAN port of the router going to the cable modem. All clients are Wifi.

The node is 192.168.1.60 and arp -a shows 18-31-bf-e1-d4-d0 for that IP. I'm assuming the 18-31-bf-e1-d4-d1 (d1 versus d0) is ia device in the same box.

Yep, I just did a telnet ifconfig -a on the node and it shows:

wl0.1 Link encap:Ethernet HWaddr 18:31:BF:E141
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:41501 errors:0 dropped:0 overruns:0 frame:9540
TX packets:363605 errors:7 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6258505 (5.9 MiB) TX bytes:80178312 (76.4 MiB)

The only cable on the node is the power cord.

I know very little about Linux so I have no idea why the router would be logging those messages (Disassoc, etc.) for a MAC inside the node. Or the RX and TX counts for a unused Ethernet port.

After warm booting the node, the logs are still very quiet and no dropped connections so far. No lost pings either. About 20 hours of run time.

Bruce.

 

[VANT]

i downgrade fw in my node to 81039 and will be observ. Now node work ok (on 45717 i was same issue like 81049)

Stations List                           
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
2C:xx:A1:xx:69:41 Yes        Yes         -61dBm ac  No  Yes Yes  No     3  192.5M    130M 04:10:35

now my node is Authorized