What's new

Release Asuswrt-Merlin 3006.102.7 is now available

This is really wierd, am i really confused or is something wrong.. i cant find the latest release om either of the mirrors for RT-AX86U..🤔
 
This is really wierd, am i really confused or is something wrong.. i cant find the latest release om either of the mirrors for RT-AX86U..🤔
Pro?
RT-AX86U is staying on the 3004.388.x releases.
 
Has anyone else had issues with Diversion since the 3006.102.7 update? Entries in the manual allow list are ignored, rolling back to 3006.102.6 instantly resolves the issue.

I'm guessing this is connected to the dnsmasq version used?
Probably best to report your findings in the Diversion thread.
 
GT-AX6000 dirty update from 102.6 to 102.7 with no new issues noted. Running stable for a couple of days now.
I did notice that hitting "apply" on the Administration -> System tab turns ON the Aura RGB LED, so I have to remember to turn that off each time. 102.6 also had this minor inconvenience. The Aura RGB LED is not useful (too distracting) and I would prefer it to remain (as set) OFF.
 
Not sure if this is the right place to continue this topic, though it does seem related with the current GPL, including what is used for this version. I have been having instability with only one of my two nodes (BE86U with issue, BE82U no issue). IoT devices most notably would consistently lose connection, often within a day, sometimes intermittent in either direction. This is fairly consistent across firmware versions, both Merlin or stock.

Yesterday, I saw a post with reported DHCP issue when using wired VLAN, so wondered if the wired VLAN config I use for a single IoT device on the BE86U could be causing the connection drops. I changed the VLAN back to All(Default) / Default and following the change have not had a single device go offline on any node. While this has only been 1 day, 8 hours, 20 minutes; I would have had devices dropping off by now on the latest stock firmware. I have a ticket open with Asus since the GPL is closed and will report to them as well should I find that this is causing the IoT stability issues. My desire is to be able to use the wired VLAN without impacting wireless IoT VLAN, so hoping this helps isolate the issue if it does prove to be the source of the instability.
Quick update, with wired VLAN left at All(Default), I have had no client disconnects in over 3 days! This is clearly an issue (maybe the only one) that was causing wireless instability on this one mesh node. Still pending response from ASUS per my open ticket, though I will provide an update with anything relevant once they do respond.
 
Quick update, with wired VLAN left at All(Default), I have had no client disconnects in over 3 days! This is clearly an issue (maybe the only one) that was causing wireless instability on this one mesh node. Still pending response from ASUS per my open ticket, though I will provide an update with anything relevant once they do respond.
What router and nodes?
 
upgraded all 4 of my local routers bt88u gtaxe1600 x2 and gtax11000 pro.. dirty upgrades all.. no issues so far to report
 
I started getting these messages on my RT-BE88U. The transmission was installed a long time ago. This is the first time I've seen this error on this router. This didn't happen with previous firmware versions.
Feb 27 22:07:28 kernel: ===DDD===
Feb 27 22:07:28 kernel: 00400000 - 0051e000, [transmission-daemon]
Feb 27 22:07:28 kernel: 7f8b5d6000 - 7f8b5e9000, [libresolv-2.27.so]
Feb 27 22:07:28 kernel: 7f8b5fd000 - 7f8b602000, [libnss_dns-2.27.so]
Feb 27 22:07:28 kernel: 7f8b638000 - 7f8b643000, [libnss_files-2.27.so]
Feb 27 22:07:28 kernel: 7f8c72b000 - 7f8c73a000, [libintl.so.8.4.0]
Feb 27 22:07:28 kernel: 7f8c74c000 - 7f8c831000, [libiconv.so.2.7.0]
Feb 27 22:07:28 kernel: 7f8c843000 - 7f8c9ef000, [libunistring.so.5.1.0]
Feb 27 22:07:28 kernel: 7f8ca04000 - 7f8ca35000, [libidn2.so.0.4.0]
Feb 27 22:07:28 kernel: 7f8ca46000 - 7f8ca5a000, [libz.so.1.3.1]
Feb 27 22:07:28 kernel: 7f8ca6c000 - 7f8cb74000, [libssl.so.3]
Feb 27 22:07:28 kernel: 7f8cb94000 - 7f8cb96000, [libdl-2.27.so]
Feb 27 22:07:28 kernel: 7f8cba8000 - 7f8cbba000, [libgcc_s.so.1]
Feb 27 22:07:28 kernel: 7f8cbcb000 - 7f8cc7d000, [libm-2.27.so]
Feb 27 22:07:28 kernel: 7f8cc8f000 - 7f8cdd9000, [libstdc++.so.6.0.25]
Feb 27 22:07:28 kernel: 7f8cdfa000 - 7f8ce05000, [libutp.so]
Feb 27 22:07:28 kernel: 7f8ce1b000 - 7f8ce28000, [libminiupnpc.so.2.2.8]
Feb 27 22:07:28 kernel: 7f8ce39000 - 7f8ce3b000, [libnatpmp.so.20230423]
Feb 27 22:07:28 kernel: 7f8ce4c000 - 7f8ce5d000, [libpsl.so.5.3.5]
Feb 27 22:07:28 kernel: 7f8ce6e000 - 7f8cf02000, [libcurl.so.4.8.0]
Feb 27 22:07:28 kernel: 7f8cf19000 - 7f8d3e7000, [libcrypto.so.3]
Feb 27 22:07:28 kernel: 7f8d46b000 - 7f8d47b000, [libdeflate.so.0]
Feb 27 22:07:28 kernel: 7f8d48c000 - 7f8d4a5000, [libpthread-2.27.so]
Feb 27 22:07:28 kernel: 7f8d4ba000 - 7f8d503000, [libevent-2.1.so.7.0.1]
Feb 27 22:07:28 kernel: 7f8d515000 - 7f8d66b000, [libc-2.27.so]
Feb 27 22:07:28 kernel: 7f8d684000 - 7f8d68b000, [libatomic.so.1.2.0]
Feb 27 22:07:28 kernel: 7f8d69e000 - 7f8d6bd000, [ld-2.27.so]
Feb 27 22:07:28 kernel: CPU: 1 PID: 7159 Comm: transmission-da Tainted: P O 4.19.294 #1
Feb 27 22:07:28 kernel: Hardware name: Broadcom-v8A (DT)
Feb 27 22:07:28 kernel: pstate: 80000000 (Nzcv daif -PAN -UAO)
Feb 27 22:07:28 kernel: pc : 0000000000478b4c
Feb 27 22:07:28 kernel: lr : 0000000000478b24
Feb 27 22:07:28 kernel: sp : 0000007f8c6f8f90
Feb 27 22:07:28 kernel: x29: 0000007f8c6f8f90 x28: 0000000000531000
Feb 27 22:07:28 kernel: x27: 000000000052fc80 x26: 0000007f7c008cc0
Feb 27 22:07:28 kernel: x25: 000000003c19cfe8 x24: 0000000000000001
Feb 27 22:07:28 kernel: x23: 0000000000000000 x22: 00000000004f9fc0
Feb 27 22:07:28 kernel: x21: 0000007f8431c000 x20: 0000007f7c008cb0
Feb 27 22:07:28 kernel: x19: 0000007f8c6f90e8 x18: 0000000000000001
Feb 27 22:07:28 kernel: x17: 0000007f8d5980c0 x16: 000000000052f308
Feb 27 22:07:28 kernel: x15: 0000000000000010 x14: 000000002e1f5698
Feb 27 22:07:28 kernel: x13: 0000000000000002 x12: 00000000000beacc
Feb 27 22:07:28 kernel: x11: 00000000000035b6 x10: 000000003c1a4f10
Feb 27 22:07:28 kernel: x9 : 0000000000000030 x8 : 0000007f8c6f90e8
Feb 27 22:07:28 kernel: x7 : 0000007f841dcf80 x6 : 0000007f84341ae8
Feb 27 22:07:28 kernel: x5 : 0000007f843a0a54 x4 : 0000007f8c6f91e0
Feb 27 22:07:28 kernel: x3 : 0000007f8c6f91b0 x2 : 000000000000dcde
Feb 27 22:07:28 kernel: x1 : 0000000000000048 x0 : 0000007f8c6f9130
 
I FINALLY solved the ipv6 dropping after 2 hours , I asked claude (I cant take credit for this , claude walked me through the whole thing and creating the fix) to sum up the issue I was facing and the fix that works for me , this is what it wrote . Any feedback from a human being on if this looks like a solid fix or not would be greatly appreciated!

IPv6 dies every ~2 hours on Asus GT-AXE16000 Merlin - SOLVED
Setup:
Asus GT-AXE16000 running Merlin firmware, Telus 1G Fibre (Calgary AB), ONT in bridge mode, WAN straight ethernet (no PPPoE), ControlD DoT.

The Problem:IPv6 would work perfectly after making any change on the router's IPv6 GUI page and clicking Apply, but would die approximately 2 hours later. The only way to restore it was to toggle a setting in the GUI (just clicking Apply wasn't enough — an actual setting change was required).

Root Cause:Merlin starts odhcp6c (the DHCPv6 client) correctly when the IPv6 GUI page is saved. However, odhcp6c was dying sometime before the lease renewal point (~2 hours). When it died, the IPv6 default route expired and nothing in Merlin automatically restarted it. There is no built-in watchdog for odhcp6c in Merlin firmware.

The bug:odhcp6c was dying before it ever got to the renewal point. We don't know exactly why it was dying , possibly :
  • A memory issue in this version of odhcp6c
  • A signal being sent to it by another Merlin process
  • A Merlin internal process inadvertently killing it during some background maintenance task
The Fix:A watchdog script at /jffs/scripts/ipv6-watchdog.sh that runs every 5 minutes via cron and checks three things:
  • Is odhcp6c running?
  • Does an IPv6 default route exist on eth0?
  • Does br0 have a global IPv6 address?
If any of these fail, it kills any stale odhcp6c process, cleans up the pidfile, and restarts odhcp6c with the exact command Merlin uses:

bash
odhcp6c -df -R -s /tmp/dhcp6c -N try -c 00030001a036bc71b554 -P 56:1b558 -r23 -r24 -k eth0

Note: The -c value is your router's DUID (unique per router), and -P 56:1b558 requests a /56 prefix delegation with your specific interface ID. These values can be found by running ps | grep odhcp6c immediately after a GUI apply while IPv6 is working.

Key facts for others with this issue:
  • /tmp/dhcp6c is a symlink to /sbin/rc — Merlin's internal state-change handler, don't change this
  • The DUID (-c value) is unique to your router — get yours from ps output
  • No VLAN tagging needed on Telus FTTH if IPv4 is already working untagged
  • logread doesn't work on this router — no syslog buffer available
  • The watchdog is added to /jffs/scripts/services-start for reboot persistence
Confirmed working — watchdog log showed it catching and fixing the dropout automatically at the 2-hour mark without any manual intervention.
 
Thank you as always!
If anyone installs this on their (ROG) GT-AX11000 Pro, would appreciate andy follow ups/comments. Both the August and November releases displayed quirks, was awating this to see how it goes. Good weekend to all, S.
 
All good here on GT-AXE16000.

I was also having issues with IPv6 on the previous releases and had assumed this was caused by something that my ISP (Connect Fibre - UK) had changed/broke and didn’t think to troubleshoot here. All working nicely again.

HB
 
Can anyone help with these log entries. I have just replaced an RT-AX88U with a RT-BE88U, flashed to 3006.102.7 and these entries are repeating in the log - specifically in the messages tab in scribe - as they were not there with the AX88U I would like to know what they are, are they normal for this router, is it anything to do with this firmware, do I need to do anything, etc.
Code:
...
Feb 28 18:04:35 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:37 Router kernel: SBF: dhd1: INIT [8c:5a:25:4e:fa:08] ID 65535 BFW 65535 THRSH 2048
Feb 28 18:04:41 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:41 Router kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Feb 28 18:04:41 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:44 Router kernel: SBF: dhd1: INIT [8c:5a:25:4e:fa:08] ID 65535 BFW 65535 THRSH 2048
Feb 28 18:04:48 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:48 Router kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Feb 28 18:04:48 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:51 Router kernel: SBF: dhd1: INIT [8c:5a:25:4e:fa:08] ID 65535 BFW 65535 THRSH 2048
Feb 28 18:04:55 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:55 Router kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
...
 
I have a web gui logout issue when i scan an usb flash disk for bad sectors after router power on from the gui front page. I don't have any scripts running from the usb flash (no amtm, no entware, no swap, etc on the flash drive), except traffic analyzer stats are routed there for permanent storage. In the middle of the scanning, at some point the web gui logout by itself! Same issue in th 107_beta1. I know that the stats engine was changed recently, but in all differents versions of router and firmware i used so far with the stats configured on the usb flash disk, i never seen this kind web gui logout behavior. The only thing i experimented previously was that some time i have to rescan the flash more than once to be in an healthy state.
 
Can anyone help with these log entries. I have just replaced an RT-AX88U with a RT-BE88U, flashed to 3006.102.7 and these entries are repeating in the log - specifically in the messages tab in scribe - as they were not there with the AX88U I would like to know what they are, are they normal for this router, is it anything to do with this firmware, do I need to do anything, etc.
Code:
...
Feb 28 18:04:35 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:37 Router kernel: SBF: dhd1: INIT [8c:5a:25:4e:fa:08] ID 65535 BFW 65535 THRSH 2048
Feb 28 18:04:41 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:41 Router kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Feb 28 18:04:41 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:44 Router kernel: SBF: dhd1: INIT [8c:5a:25:4e:fa:08] ID 65535 BFW 65535 THRSH 2048
Feb 28 18:04:48 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:48 Router kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Feb 28 18:04:48 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:51 Router kernel: SBF: dhd1: INIT [8c:5a:25:4e:fa:08] ID 65535 BFW 65535 THRSH 2048
Feb 28 18:04:55 Router kernel: WLC_SCB_DEAUTHORIZE error (-30)
Feb 28 18:04:55 Router kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
...
I seen similar on mine but not so heavily, not related to this specific merlin release, since I got the router. Everything is working fine so I ignore it. I do wonder if the same message appears on the stock firmware.
 

Similar threads

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!
Back
Top