What's new

Beta Asuswrt-Merlin 386.1 Beta 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!

Status
Not open for further replies.
The 2.4 GHZ I guest uses 192.168.101.0/24 and the 5 GHZ first guest uses 192.168.102.0/24.
Si why 192.168.102.x1 and 192.168.102.x2 255.255.255.0 unable to communicate with each other?I'm trying to get a VU 2 set-top box to send a stream to a cell phone. Both guest online. It just won't work
Try the 2nd guest network. Might also set DNS filter to unfiltered for the clients.
 
Exactly what I have running successfully - see my signature. HOWEVER - there seems to be a bug with the AC5300 and Aimesh when it comes to Guest Network 1 propagation from Router to Node - that part not running yet and awaiting a fix from Asus [also affects the AC3100 I believe].

Just tried it now. But my clients are bouncing around like a ping pong. Some clients won’t connect back.
Edit: rebooted ac86u router and it seems to be okay for now.

Guest wifi is populating on GT-AC5300 node. I see it connected and it gives out a 192.168.101.x instead of 192.168.2.x (Guest WiFi network 1)

YazFi works but it doesn't see the Guest VLAN that is created on the guest node (I think). I have to see if I can change my IOT device from my homebridge to point to 192.168.101.x and if its reachable.

Edit: changed the IP in HomeBridge I can communicate to my IOT device now. Only problem is if it jumps nodes the IP will change; unless I bind it to the ac5300 node.
 
Last edited:
Hi,
Looking at your screenshot, Did you setup you WAN -> DDNS ?
Hi bud,yup,I had established the DDNS.And I'm using the DDNS(from no-ip.com)for both Openvpn and IPSec.
IPSec IKEv1 works great but IKEv2....liked the pic I shown you.:(
 
I updated from a4 to b1 a few days ago.

To be sure I also did a clean install.. Initially I encountered some problems when configuring.. I then did a factory reset again.. After this, configuring went well and everything runs fine (just as a4, that one also worked fine). Uptime 2 days, no strange entries seen in logs. For now guest wifi is disabled, ddns working, vpn with selective routing working fine.

There appears to be 2 methods to reset the ax88 (and other models as well). I wonder what are the differences:

1. Switch on the router while keeping the wpa button pressed. Wait until the power led goes off. Then switch of the router again and then switch the router on

2. Keep the reset button pressed (with a paper clip) and wait until the led start to flash...

Update:
I found this topic from 2013 and it refers to an AC68U router:

AC68U - Reset button and WPS 30 seconds, what and how... | SmallNetBuilder Forums (snbforums.com)

It appears that both methods do the same...
 
Last edited:
Just want to throw this out there one more time. A factory reset is necessary with this release!
If upgrading from the alpha. And recommended if coming from stock.

I haven't seen any posts to say that dirty flashing from the 384 series would cause specific issues. (Though I haven't completely combed the thread yet).
 
Just want to throw this out there one more time. A factory reset is necessary with this release!
A lot of problems posted here are a direct result of not doing a factory reset or doing a factory rest improperly. When you do a factory reset make sure you don't restore your settings from a saved backup. It's also recommended to format the JFFS partition after you updated to the new release. And be sure to give your router plenty of time to complete its bootup process after each restart, especially if you do a JFFS partition format. This is not something you can rush in 5 minutes; this needs time to do it properly.

I agree, and I really did plan on doing a factory reset on my ax88u, which I upgraded from Alpha 4, but have not gotten around to it. Nonetheless, everything seems to be running well. I'm puzzled as to why. Is it because I also did not do a factory reset on any of the alphas so the NVRAM is still what it was with the last stock version? At any rate, I'll likely do the reset this weekend when folks are not cranking on working at home.
 

After activating the first guest network on the left for my devices.
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
Dec 8 18:12:58 kernel: protocol 0800 is buggy, dev eth6
As soon as I turn off 1 guest network and turn on 3, this error disappears from the log.

And yes, in the settings of this network there really was an item for expanding the network in Aimesh

1607440554753.png
 
Last edited:
I have the extra stuff at the bottom on the VPN Server page. Router is RT-AX86. See image.

Something is preventing that page from loading properly. Open your browser console and look for Javascript errors.

On my RT-AC68U went from 384.19 to 386.1_beta1 (dirty flash) and it looks like the intermittent traffic spike is back.

It's a long-standing issue in the traffic monitoring code. My firmware was unaffected until now because I was still using much older code that didn't have the issue, however with 386 I had to re-sync with Asus's own code due to numerous other fixes/changes they did, causing the bug to be introduced in my firmware as well. I am unable to reproduce it here, so I have no idea what is causing it.
 
ac66u-b1 update from 384.19 to 386.1 beta. do i need to factory reset?

everything worked for a day or two then i lost all wifi and had to reboot router. noticed after first upgrading aimesh option in gui was missing the icon on he button. i am not using aimesh but after reboot i see the aimesh icon there maybe that means something is more stable now hopefully.

i also notice that guest networks now have different ip ranges?

i didn't see any messages in syslog when the wifi dropped out i upped the log level and will post back if it happens again.


update: seems only guest network 1 for 2.4 and 5ghz have different ip ranges. not guest networks 2 and 3.

getting this is syslog Dec 8 10:41:44 kernel: nvram: consolidating space! think i saw this mentioned somehwere else, i might do a facotry reset and jffs format and see if i have issues.
 
Last edited:
Seeing these messages on RT-AX58U with latest 386.1 Beta 1 release. Not a critical issue or anything, just curious what these kernel messages are and if our fellow RT-AX58U users on latest 386.1 Beta 1 are seeing same messages. Noticed that @Trent Hubbert got these messages a couple months back on 384.19 Beta 1.

Dec 7 22:22:47 kernel: SUSPREQ 0 SUSPREQ1 0 SUSPREQ2 0
Dec 7 22:22:47 kernel: CHNSUSP_STATUS 0 CHNSUSP_STATUS1 0 CHNSUSP_STATUS2 0
Dec 7 22:22:47 kernel: FLUSHREQ 0 FLUSHREQ1 0 FLUSHREQ2 0
Dec 7 22:22:47 kernel: CHNFLUSH_STATUS 0 CHNFLUSH_STATUS1 0 CHNFLUSH_STATUS2 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x10000 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 0:
Dec 7 22:22:47 kernel: RX0: DMA64: rxd64 d6c10000 rxdpa 0x16c10000 rxdpahi 0x0 head d95fc740 tail d9696e40 rxin 1033 rxout 1533
Dec 7 22:22:47 kernel: rcvcontrol 0x36c0851 rcvaddrlow 0x16c10000 rcvaddrhigh 0x0 rcvptr 0x5fd0 rcvstatus0 0x20004090 rcvstatus1 0x4120 rxfilled 500
Dec 7 22:22:47 kernel: currdescr 1033 activedescr 1042 lastdescr 1533
Dec 7 22:22:47 kernel: rxuflo 0
Dec 7 22:22:47 kernel: TX0(p32): DMA64: txp (null) txd64 d51f0000 txdpa 0x151f0000 txdpahi 0x0 head (null) tail d56cb200 txin 6 txout 6 txavail 2047 txnodesc 0 flags:0x19c00
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x151f0000 xmtaddrhigh 0x0 xmtptr 0x60 xmtstatus0 0x20008980 xmtstatus1 0xca30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: txuflo 0
Dec 7 22:22:47 kernel: AQM0: DMA64: txp (null) txd64 d6c74000 txdpa 0x16c74000 txdpahi 0x0 head (null) tail (null) txin 6 txout 6 txavail 1023 txnodesc 0 flags:0x500
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x16c74000 xmtaddrhigh 0x0 xmtptr 0x4060 xmtstatus0 0x10004060 xmtstatus1 0x4060
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 1:
Dec 7 22:22:47 kernel: RX1: rxuflo 0
Dec 7 22:22:47 kernel: TX1(p33): DMA64: txp (null) txd64 d9078000 txdpa 0x19078000 txdpahi 0x0 head (null) tail d5708e40 txin 1187 txout 1187 txavail 2047 txnodesc 0 flags:0x19c00
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x19078000 xmtaddrhigh 0x0 xmtptr 0xca30 xmtstatus0 0x20008980 xmtstatus1 0xca30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: txuflo 0
Dec 7 22:22:47 kernel: AQM1: DMA64: txp (null) txd64 d6c04000 txdpa 0x16c04000 txdpahi 0x0 head (null) tail (null) txin 224 txout 224 txavail 1023 txnodesc 0 flags:0x500
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x16c04000 xmtaddrhigh 0x0 xmtptr 0x4e00 xmtstatus0 0x10004e00 xmtstatus1 0x4e00
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 2:
Dec 7 22:22:47 kernel: RX2: rxuflo 0
Dec 7 22:22:47 kernel: TX2(p34): DMA64: txp (null) txd64 d6ca8000 txdpa 0x16ca8000 txdpahi 0x0 head (null) tail d33b6740 txin 6 txout 6 txavail 2047 txnodesc 0 flags:0x19c00
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x16ca8000 xmtaddrhigh 0x0 xmtptr 0x8060 xmtstatus0 0x20008980 xmtstatus1 0xca30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: txuflo 0
Dec 7 22:22:47 kernel: AQM2: DMA64: txp (null) txd64 d73f0000 txdpa 0x173f0000 txdpahi 0x0 head (null) tail (null) txin 3 txout 3 txavail 1023 txnodesc 0 flags:0x500
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x173f0000 xmtaddrhigh 0x0 xmtptr 0x30 xmtstatus0 0x10000030 xmtstatus1 0x30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 3:
Dec 7 22:22:48 kernel: dmada 0 dmade 0 rxoflo 0 dmape 0
Dec 7 22:22:48 kernel: txerr mac 0200 phy 8280 0000 0200 tst 2020 dur 0014
Dec 7 22:22:48 kernel: pctlen 0014 pctls 0a40 0000 0003 0000 0000 0000
Dec 7 22:22:48 kernel: plcp 00b4 0000 || 040a 05a0 0000 || 0000 0000 || 00
 
Just tried it now. But my clients are bouncing around like a ping pong. Some clients won’t connect back.
Edit: rebooted ac86u router and it seems to be okay for now.

Guest wifi is populating on GT-AC5300 node. I see it connected and it gives out a 192.168.101.x instead of 192.168.2.x (Guest WiFi network 1)

YazFi works but it doesn't see the Guest VLAN that is created on the guest node (I think). I have to see if I can change my IOT device from my homebridge to point to 192.168.101.x and if its reachable.

Edit: changed the IP in HomeBridge I can communicate to my IOT device now. Only problem is if it jumps nodes the IP will change; unless I bind it to the ac5300 node.

Glad things seem to be working out for you - my setup is now fully stable - BUT I am not able to use Guest1 WiFi without the issues reported in this thread ...
http://www.snbforums.com/threads/386-1-b1-on-rt-ac86u-log-spam-protocol-0800-is-buggy.68240/

Maybe it only occurs if, like me, you are using QoS and Guest1 WiFi ?
 
I was one of the users that experienced a high degree of instability of 384.19 on my RT-AC86U as a main node, so I went back to 384.18 (where everything is humming along nicely). I make use of an external USB stick for amtm and scripts. I am presuming that I also have the "old" configuration for the JFFS partition size.

Are there any kind souls reading this who can suggest or document the correct upgrade path to go from 384.18 to 386.1 b1 on an RT-AC86U? I would really love to be able to restore the content of the JFFS partition and current router config, if at all possible, post-upgrade. Thanks in advance!
 
Might be coincidence, but I can't get on my customer's VPN (using Cisco AnyConnect) since I upgraded to 386.1 Beta 1.

Investigating...
Coincidence!

After two entire work days (lost) IT finally found & fixed a server side issue...
 
Asus have released an update for the RT-AX88U. (386_41249)

1) Would Merlin's beta firmware be older or newer than nthe Asus firmware?

2) As I am on stock, would it be better to first update router to latest Asus firmware, and then update to Merlin to avoid having to factory reset ?
 
Glad things seem to be working out for you - my setup is now fully stable - BUT I am not able to use Guest1 WiFi without the issues reported in this thread ...
http://www.snbforums.com/threads/386-1-b1-on-rt-ac86u-log-spam-protocol-0800-is-buggy.68240/

Maybe it only occurs if, like me, you are using QoS and Guest1 WiFi ?

I'm not using QoS, I find it to finicky so I choose to keep it disabled. Just have my IOT devices on Guest1 WiFi with "all" nodes extended.

However, I do experience an issue every couple of hours where the ac86u just takes a dump; all the clients gets disconnected and connects to the aimesh node. from a client perspective it doesn't see the disconnect but i'll be connected to the ac5300 aimesh node and internet works fine. after about 5 minutes it ping pongs back to 86u depending on signal strength.
 
Asus have released an update for the RT-AX88U. (386_41249)

1) Would Merlin's beta firmware be older or newer than nthe Asus firmware?

2) As I am on stock, would it be better to first update router to latest Asus firmware, and then update to Merlin to avoid having to factory reset ?
@RMerlin will have to answer the first one.

EDIT: Based on Merlin's changelog, I see the following:

Source: https://www.asuswrt-merlin.net/changelog
- UPDATED: Merged GPL 386_41035 (beta GPL from Asus).

Not sure if that answers your question.

For the 2nd question, his original post outlines the recommendation when coming from stock firmware:

- If coming from stock Asus firmware, a factory default reset is recommended, but not mandatory.
 
Last edited:
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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