Beta Asuswrt-Merlin 386.2 Beta is now available

[JR Godwin]

I have seen this issue where the dhcp manual assignments get dropped very occasionally in the past. Usually the dhcp server assigns the correct IPs to devices so I just re-added the manual assignments and was done.

I think you have quite a few manually assigned IPs so it might be worth installing YazDHCP that allows you to hold many more entries (as the high number of manual dhcp assignments might be what has caused this issue in the first place).

Sorry I can't be more help.

I'm on an AX-86U, and have 18 manual assignments not utilising YazDHCP....they came back fine.

 

[Sicario]

Did not know when though... (expected/hoped this weekend)

it's been updated tho'

Beta - Asuswrt-Merlin 386.2 Beta is now available

20-March-2021: Beta 2 is now available. Changes since Beta 1: snip... I'm looking for more feedback from RT-AX68U and GT-AX11000 owners. Possibly not that useful but I have installed beta 2 on my AX11000 last night. I'm using the AX11000 as the AiMesh main node with two XT8 nodes. I'm not...

www.snbforums.com

 

[netsurfer]

I am on AC-86U came from stock 386.41634 to 386.2 beta1 (clean install/hw reset) Worked like a charm with more stability and no issues. Cake enabled with about 20 clients (cams, tv, mobile devices, computers)
Upgraded to beta2 which worked fine for about 4-5 days and then yesterday evening I got occasional spinning wheels in Netflix and youtube before loosing network completely. Over wifi I could reach the router it self and everything looked good in the gui and syslog. Tried a ping to google under nw tools but nothing, it didn't evening initiate. Rebooted the router and everything worked again. I found nothing in the syslog that would indicate something went wrong. I am now on b3, which is stable so far after a few hours. Lets see after 2-3d.

To be honest I had similar problems on stock 386.41634 but there the nw map told me there are issues with my wan dhcp when I lost nw uplink - not the case here on Merlin. My ISP got 20 minute lease time on the dhcp IP. I got a feeling this could be related to my issues. They mainly started when moving from stock 384.x to 386.x.

 

[KentEkl]

Tor is resetting the configuration after every restart of the router.
I have configured Redirect all user from "Only Specified MACs" but the router drops that configuration and set it to Redirect all user from
to "LAN(br0)" and removes all entries from Specified MAC List every time the router RT-AC86U with 386.2_beta3 is restarted.

 

[XIII]

it's been updated tho'

Beta - Asuswrt-Merlin 386.2 Beta is now available

20-March-2021: Beta 2 is now available. Changes since Beta 1: snip... I'm looking for more feedback from RT-AX68U and GT-AX11000 owners. Possibly not that useful but I have installed beta 2 on my AX11000 last night. I'm using the AX11000 as the AiMesh main node with two XT8 nodes. I'm not...

www.snbforums.com

Yes, I know (last week I knew the update was coming, but not when - I was pleased to see it yesterday; that was what I was trying to say in my previous post)

 

[Unisoft]

Applied Beta3 over Beta2. All fine here, no issues. 2 AX86U and one AC86U updated.

 

[shabbs]

I'm on an AX-86U, and have 18 manual assignments not utilising YazDHCP....they came back fine.

RT-AX88U here with around 15 manual assignments, they call came back after the upgrade here.

 

[Mutzli]

Upgraded all my routers from Beta 2 to 3 about 24h ago. So far everything works fine without any issues.

 

[GHammer]

Hi! Not using YazDHCP. Had to do a web search to even know what it was, sorry. I've looked around a bit, and noticed that in the nvram, there is no 'dhcp_hostnames=' entry (an empty definition). There are both empty and filled entries for dhcp_staticlist and custom_clientlist, but no empty entry for dhcp_hostnames.

This is one reason I went with YazDHCP. It is an easier backup method than others.
Take a look at it after you get your entries in again.

 

[MvW]

Performed a dirty upgrade to Beta3 from Beta2 this afternoon. The functionality seems fine. HOWEVER, on the LAN page / the DHCP Server tab, the table of defined clients is empty (I have 23 defined). The /jffs/nvram files dhcp_hostnames and custom_clientlist are both the same as in earlier firmware versions with the 23 entries. On the Network Map page's Client List pop-up the entries are correct in terms of the host's names and IP and MAC addresses, as well as their new icons. Sorry, I cannot for certain say that it was filled in with Beta2. The device is an RT-AX3000 running the RT-AX58U firmware.

RT-AX88U here with around 15 manual assignments, they call came back after the upgrade here.

20+ manual assignments here, all still there after a dirty upgrade. Not using YazDHCP (yet?).

 

[New2This]

Not sure if it is only me, however, I have an RT-AC5300 Router and currently running version 384.19. If I upgrade to any version after 384.19, my router becomes very unresponsive. After I upgrade to any version, the router comes up and you can connect to the router, and then about 1-2 minutes later, it reboots automatically and continues to reboot every time it restarts. I have to time it correctly to revert back to 384.19 and then my router works perfectly.

Anyone having this issue? Is there a way to fix this?

thanks

Reset the router,give it a nuke, when you can back online it will ask you to upload new firmware, that’s where you can upload the new beta.

 

[LimJK]

Hi,

Observation of WiFi 2.4GHz issue on RT-AC86U AiMesh Nodes.

Over the last few months I observed that with both Stock / Merlin Firmware(s), the 2.4GHz band on both my RT-AC86U AiMesh Nodes at times degraded from 3 streams (Max Rate of 216.7 mbps) to 1 stream (Max Rate of 72.2 mbps). It has not happened to my RT-AX88U AiMesh Router.

It has happened on both my RT-AC86U AiMesh Nodes, but, only on one AiMesh Node each time with a new FirmWare Upgrade:

• When / How this happened was totally unpredictable; it can be within 1-2 hour, 1-2 days or 1-2 weeks (I have not tried for months, as I am very current on testing new Stock/Merlin Firmwares upgrade)
• So far once the degradation from 3 streams to 1 stream happened, it will stay at 1 stream, till I did my workaround.
• I use default ASUS or Merlin Wireless NVRAM defaults, except with Fixed Control Channel and Fixed Bandwidth (2.4GH CH:11 BW:20MHz, 5GHz CH:149 BW:80MHz)

My workaround includes:

• Powering OFF / ON the offending AiMesh Node (works most of the time)
• Use AiMesh 2.0 GUI to Remove / Add Node (seems most effective)
• Rebooting offending Node over AiMesh 2.0 GUI (does not seem to help for my case)

I have not reported it so far because:

• I am unable to recreate the degradation in a repeatable manner
• I hardly use 2.4GHz band for our roaming mobile devices at home

PS:

• I am waiting for ASUS to release their RT-AC86U 3.0.0.4_386_42095 or newer for me to use and send feedback to them.
• I use WiFi Explorer App on my MacBookPro that shows me the number of streams on my AiMesh Router and Nodes.

 

[skeal]

Nice work @RMerlin everything running great on my AX88U.

 

[gerardr]

I reverted to 386.1_2, performed an 'nvram erase' and reset everything. The DHCP manual assignment table is now displayed in 386.1_2 (as part of my debugging, it had stopped showing even in that release, pushing me to do the 'nvram erase'). HOWEVER, there's another issue that has survived the 'nvram erase', which I'll post in a separate reply.

 

[gerardr]

There's an NTP issue, which is showing in 386.1_2 as well as 386.2_beta2/3. The ntp daemon is only opening an IPv6 port for supporting LAN clients. Since my ISP is IPv4 only, I disable IPv6 on the IPv6 page, but only an IPv6 port is opened. Here's output from a couple of relevant commands that illustrate what I'm talking about. Note that this is from 386.1_2, the release to which I reverted after issues with 386.2_betas (see above), and performed an 'nvram erase'.

graxadm@grax: netstat -peanut | egrep -v 'TIME_WAIT'\|'ESTABLISHED'
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name   
tcp        0      0 0.0.0.0:5152            0.0.0.0:*               LISTEN      0          370        274/envrams         
tcp        0      0 0.0.0.0:18017           0.0.0.0:*               LISTEN      0          450        1023/wanduck       
tcp        0      0 127.0.0.1:47753         0.0.0.0:*               LISTEN      0          6265       2239/mcpd           
tcp        0      0 0.0.0.0:7788            0.0.0.0:*               LISTEN      0          7292       1905/cfg_server     
tcp        0      0 192.168.50.1:80         0.0.0.0:*               LISTEN      0          7958       2380/lighttpd       
tcp        0      0 127.0.0.1:880           0.0.0.0:*               LISTEN      0          5154       1230/httpd         
tcp        0      0 192.168.50.1:880        0.0.0.0:*               LISTEN      0          5153       1230/httpd         
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      0          17087      3695/dnsmasq       
tcp        0      0 192.168.50.1:53         0.0.0.0:*               LISTEN      0          17085      3695/dnsmasq       
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      0          17068      3692/stubby         
tcp        0      0 192.168.50.1:22         0.0.0.0:*               LISTEN      0          2602       1084/dropbear       
tcp        0      0 192.168.50.1:1080       0.0.0.0:*               LISTEN      0          6688       2393/ssh           
tcp        0      0 127.0.0.1:5916          0.0.0.0:*               LISTEN      0          882        1955/acsd2         
udp        0      0 0.0.0.0:9999            0.0.0.0:*                           0          2748       1241/infosvr       
udp        0      0 127.0.0.1:42032         0.0.0.0:*                           0          881        1955/acsd2         
udp        0      0 127.0.0.1:53            0.0.0.0:*                           0          17086      3695/dnsmasq       
udp        0      0 192.168.50.1:53         0.0.0.0:*                           0          17084      3695/dnsmasq       
udp        0      0 127.0.1.1:53            0.0.0.0:*                           0          17067      3692/stubby         
udp        0      0 0.0.0.0:67              0.0.0.0:*                           0          17081      3695/dnsmasq       
udp        0      0 0.0.0.0:18018           0.0.0.0:*                           0          451        1023/wanduck       
udp        0      0 0.0.0.0:7788            0.0.0.0:*                           0          7293       1905/cfg_server     
udp        0      0 127.0.0.1:59032         0.0.0.0:*                           0          2623       1148/wlceventd     
udp        0      0 127.0.0.1:47032         0.0.0.0:*                           0          7324       1586/roamast       
udp        0      0 127.0.0.1:61689         0.0.0.0:*                           0          3241       1316/mastiff       
udp        0      0 :::123                  :::*                                0          7484       2233/ntp           
graxadm@grax: lsof -nPp 2233
COMMAND  PID    USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
ntp     2233 graxadm  cwd       DIR   0,12     1712    1 /
ntp     2233 graxadm  rtd       DIR   0,12     1712    1 /
ntp     2233 graxadm  txt       REG   0,12   519260 4220 /bin/busybox
ntp     2233 graxadm  mem       REG   0,12    67348 3845 /lib/libresolv.so.2
ntp     2233 graxadm  mem       REG   0,12    17948 4100 /lib/libnss_dns.so.2
ntp     2233 graxadm  mem       REG   0,12    38500 4097 /lib/libnss_files.so.2
ntp     2233 graxadm  mem       REG   0,12  1242964 4054 /lib/libc.so.6
ntp     2233 graxadm  mem       REG   0,12   120500 3819 /lib/libgcc_s.so.1
ntp     2233 graxadm  mem       REG   0,12   714224 4057 /lib/libm.so.6
ntp     2233 graxadm  mem       REG   0,12    30208 4086 /lib/libcrypt.so.1
ntp     2233 graxadm  mem       REG   0,12   138508 4098 /lib/ld-linux.so.3
ntp     2233 graxadm    0u      CHR    1,3      0t0 1028 /dev/null
ntp     2233 graxadm    1u      CHR    1,3      0t0 1028 /dev/null
ntp     2233 graxadm    2u      CHR    1,3      0t0 1028 /dev/null
ntp     2233 graxadm    3u  netlink             0t0  155 unknown protocol: 31
ntp     2233 graxadm    4u  netlink             0t0  156 unknown protocol: 31
ntp     2233 graxadm    5u     IPv6   7484      0t0  UDP *:123

 

[niugrtb]

Hi everyone, I have the latest stable FW 386.1_2 on my RT-AC88U and it is really wonderful and stable and I first want to thank @RMerlin for this work!
But since I have an active secondary WAN in Cold-Standby mode, I see almost equal DL and UL internet traffic as you can see in attachment. Am I the only one and is there a solution to restore real traffic without shutting down secondary WAN mode ?
Thanks a lot

 

[ka81]

Just installed RT-AC88U_386.2_beta3.trx on AC88U.
Sony TV connected to router with wifi AC. When watching FullHD channels through IPTV (OTTplayer + playlist) - it freezes too often.
Installed official asus firmware - no problem.
Could smbd help with info - what can be wrong in situation with merlin fw ? Maybe some settings to change ?..

Anyway, thanks!!

 

[AnClar]

Reset the router,give it a nuke, when you can back online it will ask you to upload new firmware, that’s where you can upload the new beta.

Also running an RT-AC5300 as master router in an AIMesh configuration with three RT-AC68U units as nodes, wireless backhaul, currently on 386.1_2 no major problems. I did have a problem after one dirty update back when I was running 384.19 in which the router would reboot every few minutes. I did a factory reset, completely nuked everything, and reinstalled from Recovery Mode. That resolved the rando reboot issues for me. Since then, I've updated several times, including from 384.19 to 386 and beyond. All of those updates have been dirty, and the router has remained stable thus far, as has the AIMesh configuration. I also had one update in which the UI was sluggish immediately post-upgrade. That condition resolved on its own after about an hour of uptime...most probably after the router completed a database update. All I can add to the conversation is to agree with New2This in suggesting a total nuke of the router, and a clean reinstall and hand reconfiguration.

 

[kernol]

Dirty from 386.2_b2 to b3 on both AX86U's - zero problems - 20+hours - all add-ons per signature running rock steady.
Thanks again to Magic Merlin and his Merry Men [and women?]

 

[doodlenoodle]

On 386.2 beta 3, ax86u. My connection felt like it was stuttering a bit while gaming, so essentially the connection felt worse right after I updated to latest beta release on time sensitive games.
I looked at cake settings and noticed my overhead values showed 36 instead of the expected 18. I was using "docsis" in the "cake-qos.conf.add" to have set as additional DLOPTIONS and ULOPTIONS.

It's worth noting that the overhead 18 and mpu 64 values were already defined in the GUI (so therefore reflected in the "cake-qos.conf"), the "docsis" value was added in "cake-qos.conf.add" as that's what I was used to doing when running earlier versions of cake installed from CLI.

At any rate, I thought the use of docsis would overwrite any overhead values already defined from the GUI but it doesn't seem like that's the case as can be seen from the screenshot. I removed docsis and now its back to overhead 18, so I'll leave it like that for the interim. Just noting my observations.