Beta Asuswrt-Merlin 3004.388.4 beta is now available

[Olivier]

Where is this STUN setting on the router? I tried everything even the on post I said fixed it did not. On a reboot it failled the only way to connect was either reboot the modem or unplg and plug back in the WAN Cat 6 on the modem.

EVERY other firmware, Merlin or stock works perfectly. Its only this release.

CC

Indeed got the same behaviour with my PPPoE connection. I have to unplug the cable modem in order to get working

 

[Damit1]

Indeed got the same behaviour with my PPPoE connection. I have to unplug the cable modem in order to get working

Happens to me as well since 388.2_2, but a reboot to the router resolves it.
Not sure why it happens, and have no time to analyze it.
Not happpens all the time, every once in so go figure this issue.

Bug BUT, I got PPPOE connection, BUT with Public IP.
Not sure what makes it that way.

 

[EPR]

Aliright, I'm in. Nasty flashed from 388.2.2. Reboot. No problem, 2 hours in...

 

[nzwayne]

Purchased a new GT-AXE16000 to replace a GT-AXE11000. Installed 388.4_Beta1 and all operational to 40x clients and three AiMesh units, except get random reboots on the AXE16000 sometimes just 15-30mins apart or can be some hours. The same code 388.4_Beta1 and setup on the AXE11000 ran perfectly.

The General log doesn't show (to me...ha..) any failure rational. Here's at example log, where the reboot seen on the lights at 07:42am.

General System Log... (BC: DD:C2:5B:AC:BD = LaCross overhead clock on a 2.5GHz Guest band setup. 192.168.50.186 = Lenovo Win11 P1G5 Laptop)
Aug 3 07:36:44 GT-AXE16000 bsd: bsd: Skip STA:02:91:27:7b:e9:1c reject BSSID
Aug 3 07:38:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:38:33 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:39:48 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: Sending act Frame to 02:91:27:7b:e9:1c with transition target eth10 ssid c8:7f:54:48:e9:1c
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: BSS Transit Response: ifname=eth8, event=156, token=9, status=6, mac=34:10:04:42:1a:59
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: BSS Transit Response: STA reject
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: Skip STA:02:91:27:7b:e9:1c reject BSSID
Aug 3 07:40:01 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:40:07 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:40:52 GT-AXE16000 miniupnpd[9897]: upnp_event_process_notify: connect(192.168.50.186:2869): Connection timed out
Aug 3 07:40:53 GT-AXE16000 miniupnpd[9897]: upnp_event_process_notify: connect(192.168.50.186:2869): Connection timed out
Aug 3 07:40:53 GT-AXE16000 miniupnpd[9897]: upnpevents_processfds: 0x15dc358, remove subscriber uuid:dd9bb24f-04f5-406b-ab3f-201bd0f0a049 after an ERROR cb: http://192.168.50.186:2869/upnp/eventing/dldjjvkgze
Aug 3 07:41:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:41:33 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:43:57 kernel: DROP IN=eth0 OUT= MAC=c8:7f:54:48:e9:1c:00:c1:b1:60:e0:19:08:00 SRC=18.67.24.198 DST=24.150.132.198 LEN=88 TOS=0x00 PREC=0x00 TTL=250 ID=22281 PROTO=TCP SPT=443 DPT=64007 SEQ=3295413980 ACK=2482497873 WINDOW=133 RES=0x00 ACK URGP=0 MARK=0x8000000
Aug 3 07:43:57 kernel: klogd: exiting
Aug 3 07:43:57 syslogd exiting
Aug 3 07:43:59 GT-AXE16000 timeserverd: Waiting for NTP to sync before starting...

Regressed the AXE16000 to 388.2_2 to see what occurs on that level. To help determine if a firmware code issue or a hardware issue with the new unit.

| Update: 10mins on 388.2_2 a reboot at 08:12. The log from that.
Aug 3 08:09:01 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:11:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:11:23 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:14:00 kernel: br0: port 6(eth6) entered forwarding state
Aug 3 08:14:00 kernel: br0: topology change detected, propagating
Aug 3 08:14:00 kernel: klogd: exiting
Aug 3 08:14:00 syslogd exiting

 

[HeadBanger]

Purchased a new GT-AXE16000 to replace a GT-AXE11000. Installed 388.4_Beta1 and all operational to 40x clients and three AiMesh units, except get random reboots on the AXE16000 sometimes just 15-30mins apart or can be some hours. The same code 388.4_Beta1 and setup on the AXE11000 ran perfectly.

The General log doesn't show (to me...ha..) any failure rational. Here's at example log, where the reboot seen on the lights at 07:42am.

General System Log... (BC: DD:C2:5B:AC:BD = LaCross overhead clock on a 2.5GHz Guest band setup. 192.168.50.186 = Lenovo Win11 P1G5 Laptop)
Aug 3 07:36:44 GT-AXE16000 bsd: bsd: Skip STA:02:91:27:7b:e9:1c reject BSSID
Aug 3 07:38:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:38:33 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:39:48 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: Sending act Frame to 02:91:27:7b:e9:1c with transition target eth10 ssid c8:7f:54:48:e9:1c
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: BSS Transit Response: ifname=eth8, event=156, token=9, status=6, mac=34:10:04:42:1a:59
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: BSS Transit Response: STA reject
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: Skip STA:02:91:27:7b:e9:1c reject BSSID
Aug 3 07:40:01 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:40:07 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:40:52 GT-AXE16000 miniupnpd[9897]: upnp_event_process_notify: connect(192.168.50.186:2869): Connection timed out
Aug 3 07:40:53 GT-AXE16000 miniupnpd[9897]: upnp_event_process_notify: connect(192.168.50.186:2869): Connection timed out
Aug 3 07:40:53 GT-AXE16000 miniupnpd[9897]: upnpevents_processfds: 0x15dc358, remove subscriber uuid:dd9bb24f-04f5-406b-ab3f-201bd0f0a049 after an ERROR cb: http://192.168.50.186:2869/upnp/eventing/dldjjvkgze
Aug 3 07:41:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:41:33 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:43:57 kernel: DROP IN=eth0 OUT= MAC=c8:7f:54:48:e9:1c:00:c1:b1:60:e0:19:08:00 SRC=18.67.24.198 DST=24.150.132.198 LEN=88 TOS=0x00 PREC=0x00 TTL=250 ID=22281 PROTO=TCP SPT=443 DPT=64007 SEQ=3295413980 ACK=2482497873 WINDOW=133 RES=0x00 ACK URGP=0 MARK=0x8000000
Aug 3 07:43:57 kernel: klogd: exiting
Aug 3 07:43:57 syslogd exiting
Aug 3 07:43:59 GT-AXE16000 timeserverd: Waiting for NTP to sync before starting...

Regressed the AXE16000 to 388.2_2 to see what occurs on that level. To help determine if a firmware code issue or a hardware issue with the new unit.

| Update: 10mins on 388.2_2 a reboot at 08:12. The log from that.
Aug 3 08:09:01 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:11:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:11:23 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:14:00 kernel: br0: port 6(eth6) entered forwarding state
Aug 3 08:14:00 kernel: br0: topology change detected, propagating
Aug 3 08:14:00 kernel: klogd: exiting
Aug 3 08:14:00 syslogd exiting

No issues here so far with GT-AXE16000 and two AX86U wired nodes.
Did you complete a full factory reset once you had flashed Merlin over the stock?

HB

 

[iceorbital]

Purchased a new GT-AXE16000 to replace a GT-AXE11000. Installed 388.4_Beta1 and all operational to 40x clients and three AiMesh units, except get random reboots on the AXE16000 sometimes just 15-30mins apart or can be some hours. The same code 388.4_Beta1 and setup on the AXE11000 ran perfectly.

The General log doesn't show (to me...ha..) any failure rational. Here's at example log, where the reboot seen on the lights at 07:42am.

General System Log... (BC: DD:C2:5B:AC:BD = LaCross overhead clock on a 2.5GHz Guest band setup. 192.168.50.186 = Lenovo Win11 P1G5 Laptop)
Aug 3 07:36:44 GT-AXE16000 bsd: bsd: Skip STA:02:91:27:7b:e9:1c reject BSSID
Aug 3 07:38:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:38:33 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:39:48 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: Sending act Frame to 02:91:27:7b:e9:1c with transition target eth10 ssid c8:7f:54:48:e9:1c
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: BSS Transit Response: ifname=eth8, event=156, token=9, status=6, mac=34:10:04:42:1a:59
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: BSS Transit Response: STA reject
Aug 3 07:39:55 GT-AXE16000 bsd: bsd: Skip STA:02:91:27:7b:e9:1c reject BSSID
Aug 3 07:40:01 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:40:07 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:40:52 GT-AXE16000 miniupnpd[9897]: upnp_event_process_notify: connect(192.168.50.186:2869): Connection timed out
Aug 3 07:40:53 GT-AXE16000 miniupnpd[9897]: upnp_event_process_notify: connect(192.168.50.186:2869): Connection timed out
Aug 3 07:40:53 GT-AXE16000 miniupnpd[9897]: upnpevents_processfds: 0x15dc358, remove subscriber uuid:dd9bb24f-04f5-406b-ab3f-201bd0f0a049 after an ERROR cb: http://192.168.50.186:2869/upnp/eventing/dldjjvkgze
Aug 3 07:41:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:41:33 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 07:43:57 kernel: DROP IN=eth0 OUT= MAC=c8:7f:54:48:e9:1c:00:c1:b1:60:e0:19:08:00 SRC=18.67.24.198 DST=24.150.132.198 LEN=88 TOS=0x00 PREC=0x00 TTL=250 ID=22281 PROTO=TCP SPT=443 DPT=64007 SEQ=3295413980 ACK=2482497873 WINDOW=133 RES=0x00 ACK URGP=0 MARK=0x8000000
Aug 3 07:43:57 kernel: klogd: exiting
Aug 3 07:43:57 syslogd exiting
Aug 3 07:43:59 GT-AXE16000 timeserverd: Waiting for NTP to sync before starting...

Regressed the AXE16000 to 388.2_2 to see what occurs on that level. To help determine if a firmware code issue or a hardware issue with the new unit.

| Update: 10mins on 388.2_2 a reboot at 08:12. The log from that.
Aug 3 08:09:01 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:11:19 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:11:23 GT-AXE16000 kernel: BC: DD:C2:5B:AC:BD not mesh client, can't update it's ip
Aug 3 08:14:00 kernel: br0: port 6(eth6) entered forwarding state
Aug 3 08:14:00 kernel: br0: topology change detected, propagating
Aug 3 08:14:00 kernel: klogd: exiting
Aug 3 08:14:00 syslogd exiting

FWIW this happened on my axe16000 as well, couple times right after upgrading to beta 1. I did update amtm scripts and uninstalled flexqos and tho I have no reason to believe any of those things were to blame, router has been good since (4 days).

 

[MDM]

Just a little curiosity (somme may have long ago noticed ) that I managed to screen-capture while refreshing the WiFi General page...
Just looks like a bunch of hidden (not user meant) FW settings

 

[Ripshod]

Just a little curiosity (somme may have long ago noticed ) that I managed to screen-capture while refreshing the WiFi General page...
Just looks like a bunch of hidden (not user meant) FW settings

Nice little nugget. Seen it myself, a gentle reminder of bygone years. When was AsusWRT born?

 

[MDM]

Nice little nugget. Seen it myself, a gentle reminder of bygone years. When was AsusWRT born?

Exactly! And this tells us the cleanliness of the code...

 

[nzwayne]

No issues here so far with GT-AXE16000 and two AX86U wired nodes.
Did you complete a full factory reset once you had flashed Merlin over the stock?

HB

Thanks. Yes a couple of times, on two fresh (no prior configs pulled in) setups of the AXE16000. Did a second whole install setup after the reboots after the first setup.

 

[RMerlin]

Just looks like a bunch of hidden (not user meant) FW settings

Settings are shown/hidden based on model and configuration. For instance all these WEP field keys would appear if you had WEP enabled.

 

[Kingp1n]

Can anyone confirm if the QoS issue for newer AX models has been fixed on this alpha/beta fw?

Thread 'Probelm with FlexQOS on AXE-16000' https://www.snbforums.com/threads/probelm-with-flexqos-on-axe-16000.84686/

Post in thread 'Asuswrt-Merlin 388.2 is now available for select models' https://www.snbforums.com/threads/a...available-for-select-models.84524/post-847382

Thread 'Display issue with FlexQoS following update' https://www.snbforums.com/threads/display-issue-with-flexqos-following-update.85395/

@RMerlin are you able to comment on QoS status for newer models? Any info is greatly appreciated!!

 

[nzwayne]

Had to swap out the AXE16000 unit back to the AXE11000 (same panel setups & physical config), too many reboots and disruptive for work & household. RMA is thought of the moment...

 

[ColinTaylor]

Had to swap out the AXE16000 unit back to the AXE11000 (same panel setups & physical config), too many reboots and disruptive for work & household. RMA is thought of the moment...

Have you tried using it with a non-beta firmware or the stock firmware? It could just be a bug in the beta firmware.

 

[nzwayne]

Have you tried using it with a non-beta firmware or the stock firmware? It could just be a bug in the beta firmware.

I felt confident to "initally" run with 388.4_B1 as running great on the AXE11000, with the updated commits on GitHub from Rmerlin since the Beta release not related to this. After the ongoing reboots on 388.4_B1 then tried the GA rmerlin code of 388.2_2, but still restarts every 30-60mins. I didn't try ASUS stock firmware (yet..) as doubted this symptom was linked to the "solid" Beta & especially the GA code. Logs not showing a clear fail, plus a brand new unit, were enough indicators to me there was a hardware issue..and...in work today to see my engineering team, ASUS service centre is only 3km away.
Update: Just back from the ASUS service centre and they were able to replicate the reboots. Now have a replacement AXE16000 to give that a whirl, starting with my saved config/jffs data from the prior unit.

 

[RMerlin]

@RMerlin are you able to comment on QoS status for newer models? Any info is greatly appreciated!!

I don`t have any info. If you are having issues with FlexQOS, then you will have to take it to its developer, as I have never looked at it.

 

[Kingp1n]

I don`t have any info. If you are having issues with FlexQOS, then you will have to take it to its developer, as I have never looked at it.

I appreciate the response.

For the new models the RMerlin code does not expect the eth5 to be WAN interface name.


Post in thread 'Probelm with FlexQOS on AXE-16000' https://www.snbforums.com/threads/probelm-with-flexqos-on-axe-16000.84686/post-838095

And a possible fix:

Post in thread 'Asuswrt-Merlin 388.2 is now available for select models' https://www.snbforums.com/threads/a...available-for-select-models.84524/post-847382

 

[dave14305]

I appreciate the response.

Merlin says he fixed the upload interface detection problem with this release.

httpd: use the phy WAN interface for bwdpi tc dumps · RMerl/asuswrt-merlin.ng@f601fe4

The previous implementation was actually correct (aside from not taking into account newer models that didn't always use eth0). On Broadcom, aQoS will always use the PHY interface.

github.com

 

[Kingp1n]

Merlin says he fixed the upload interface detection problem with this release.

httpd: use the phy WAN interface for bwdpi tc dumps · RMerl/asuswrt-merlin.ng@f601fe4

The previous implementation was actually correct (aside from not taking into account newer models that didn't always use eth0). On Broadcom, aQoS will always use the PHY interface.

github.com

Thanks @dave14305 and @RMerlin!!!

 

[Yiannis]

Merlin says he fixed the upload interface detection problem with this release.

httpd: use the phy WAN interface for bwdpi tc dumps · RMerl/asuswrt-merlin.ng@f601fe4

The previous implementation was actually correct (aside from not taking into account newer models that didn't always use eth0). On Broadcom, aQoS will always use the PHY interface.

github.com

yes, I was checking this in my PPPoE connection and stats are now showing correctly