Beta Asuswrt-Merlin 3006.102.5 Beta is now available

[casao94]

Upgraded to beta3 from beta2. Everything is working fine for me. Thanks!

 

[ExtremeFiretop]

@RMerlin

Considering you made the smart call to drop another beta, I decided to dip my toes back in with Beta3. It's much appreciated thank you again!
Here's the feedback:

1. Captive Portal issues are resolved.
-Both the original issue from 3006.102.4.0 which required a favicon file copied (scripted solution disabled before upgrade), and the newest issue from 3006.102.5.0 which caused lighttpd errors
2. The "Connections" tab correctly underlines any Public IP
-For both the Destination IP and NAT IP:

3. The "Connections" tab correctly shows routed IPv6 addresses
-The filter appears to also work as expected along with the options to display client names/auto-refresh. No issues identified with the reported data/addressing.
4. Log Spamming from coova-chilli post update?
-I was seeing this in my logs since the upgrade which is new to this firmware for me, however after doing a full reboot of the AiMesh network, the errors have since stopped.
-I see this was reported previously by @OzarkEdge here: https://www.snbforums.com/threads/a...e-version-3-0-0-6-102_33308.88454/post-916122
-Uptime is now about half an hour since the reboot and the below errors have not returned to flooding/spamming my syslog (yet?)

Jul 31 19:15:22 coova-chilli[23855]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:24 coova-chilli[23958]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:34 coova-chilli[24041]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:35 coova-chilli[24572]: ssl.c: 382: 104 (Connection reset by peer) SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
Jul 31 19:15:40 coova-chilli[24081]: ssl.c: 382: 104 (Connection reset by peer) SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
Jul 31 19:15:41 coova-chilli[24110]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:43 coova-chilli[24615]: ssl.c: 382: 104 (Connection reset by peer) SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
Jul 31 19:15:45 coova-chilli[24155]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:52 coova-chilli[6273]: chilli.c: 5173: New DHCP request from MAC=46-91-B0-EB-19-FC
Jul 31 19:15:52 coova-chilli[6273]: chilli.c: 5060: Client MAC=46-91-B0-EB-19-FC assigned IP 192.168.52.4
Jul 31 19:15:55 coova-chilli[24748]: ssl.c: 382: 104 (Connection reset by peer) SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
Jul 31 19:15:57 coova-chilli[24803]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:57 coova-chilli[24694]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:57 coova-chilli[24640]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:15:57 coova-chilli[24833]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:15:58 coova-chilli[24835]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:15:58 coova-chilli[24837]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:15:59 coova-chilli[24851]: redir.c: 2038: 104 (Connection reset by peer) SSL_read(0) failed!
Jul 31 19:15:59 coova-chilli[24862]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:16:02 coova-chilli[24875]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:16:02 coova-chilli[24895]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:16:02 coova-chilli[24896]: redir.c: 2038: 104 (Connection reset by peer) SSL_read(0) failed!
Jul 31 19:16:03 coova-chilli[24897]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:16:06 coova-chilli[24926]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:16:14 coova-chilli[24997]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:16:29 coova-chilli[25464]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:16:44 coova-chilli[6273]: chilli.c: 6125: Successful UAM login from username=noauth IP=192.168.52.4
Jul 31 19:16:50 coova-chilli[24726]: ssl.c: 382: 104 (Connection reset by peer) SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
Jul 31 19:16:57 coova-chilli[25766]: redir.c: 2038: 104 (Connection reset by peer) SSL_read(0) failed!
Jul 31 19:17:03 coova-chilli[25877]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:17:34 coova-chilli[24596]: redir.c: 63: Client process timed out: 2
Jul 31 19:17:43 coova-chilli[24676]: redir.c: 63: Client process timed out: 2
Jul 31 19:17:53 coova-chilli[24796]: redir.c: 63: Client process timed out: 2
Jul 31 19:18:07 coova-chilli[26634]: redir.c: 2038: SSL_read(0) failed!
Jul 31 19:19:41 coova-chilli[27902]: ssl.c: 384: Spurious SSL handshake interrupt [Hint: Usually just one of those OpenSSL confusions!?]
Jul 31 19:20:06 coova-chilli[28136]: redir.c: 2038: SSL_read(0) failed!

 

[RMerlin]

I like the clickable public IPs. Not as in love with the left-justified fields and the hyperlink underline makes things slightly harder (for me) to read. The centered headings feel odd when the rest is left-justified. Not deal-breakers, but initial reaction to change.

I nitially tried also left-aligning the header, but something just felt really odd with it, so I moved them back to centered. I think it might have been because of the mixture of small/wide field, so it caused some areas to be overly crowded (by the proximity of a short header and the label of the next field), with a very wide area empty of anything to the right, while with centered it made things more "roomy".

Ideally I would have liked to make the smaller fields wider so the headers wouldn't all be clustered and left-aligned headers would have looked better, but I was already scraping to save pixels here and there because of the overly wide IPv6 addresses. And that was with the compromise of resizing longer addresses to 80% font height.

I am so glad you did your detective work, this bug was not 'elementary my dear Watson'

Asus' engineers did the investigation there, and pointed me at a potential cause (which turned out to be accurate).

 

[robinjoo1]

I have replaced the driver for me Intel

That device's Ethernet port is constantly flapping, you need to figure out why. Most common cause is an out-of-spec cable that's unable to sustain a reliable 2.5 Gbps link. There are also some very buggy Intel 2.5 Gbps NICs that are notoriously bad.

yeh thanks i noticed my network type adapter is know for issues
Intel(R) Ethernet Controller (3) I225-V

 

[Blkpanthr]

strange bug, but for the last 2 betas, once i flash the time doesnt get reset correctly after the reboot and it locks out the web login once the initial login is timed out.

an additional reboot from SSH fixes it but odd...

92U

ec 31 19:00:37 kernel: skb_free_task created successfully with start budget 32, period 10ms
Dec 31 19:00:37 kernel: bcm_tcp_task created successfully with budget 256 ,cpumask:0x6
Dec 31 19:00:37 kernel: enet_kthread_init:L637 ENET system contructed and configured enet-kthrd thread
Dec 31 19:00:37 kernel: enet_kthread_handler:L595 Instantiating ENET thread
Dec 31 19:00:37 kernel: broadcomThermalDrv 8106037c.brcm-therm: init chipId 0x6765 (CPU cnt present 4 online 4 possible 4 active 4)
Dec 31 19:00:37 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 9) Link Up at 2500 mbps full duplex AN: On
Dec 31 19:00:40 kernel: eth1 (Int switch port: 5) (Logical Port: 5) (phyId: 6) Link Up at 10000 mbps full duplex AN: Off
Dec 31 19:01:14 Mastiff: init
Jul 31 18:28:36 crond[3922]: time disparity of 832227 minutes detected
Jan  9 15:16:33 crond[3922]: time disparity of 15012163 minutes detected
Jan  9 15:16:33 Aaews: >>>>>>>>>>>>>>>>>>>>>>dispatch_tunnel_event event_code = NATNL_TNL_EVENT_DEADLOCK
Jan  9 15:16:33 kernel: rcu: INFO: rcu_preempt self-detected stall on CPU
Jan  9 15:16:33 kernel: rcu:     1-...!: (3 ticks this GP) idle=0c6/0/0x1 softirq=1114906/1114908 fqs=5
Jan  9 15:16:33 kernel: rcu:      (t=900728757016 jiffies g=1309641 q=111756)
Jan  9 15:16:33 kernel: Call trace:
Jan  9 15:16:33 kernel:  __switch_to+0x148/0x170
Jan  9 15:16:33 kernel:  0x75745f6863746170
Jan  9 15:16:33 kernel: Call trace:
Jan  9 15:16:33 kernel:  dump_backtrace+0x0/0x150
Jan  9 15:16:33 kernel:  show_stack+0x14/0x20
Jan  9 15:16:33 kernel:  sched_show_task+0x100/0x120

 

[dave14305]

577dcd9134 rc: skip periodic FW checks if disabled

Just giving positive confirmation that my router has not checked for updates since installing beta3, as expected.

 

[RMerlin]

I have replaced the driver for me Intel

yeh thanks i noticed my network type adapter is know for issues
Intel(R) Ethernet Controller (3) I225-V

I had the V2 of that infamous chip on my previous motherboard. I gave up and bought a cheap Realtek PCI-E adapter that worked flawlessly until I upgrade the whole PC. I made sure this new motherboard wouldn't use an Intel chip.

And now that Intel is spinning off their network division as part of their death spiral, that doesn't exactly inspire confidence for the future of their networking products.

 

[dave14305]

Just giving positive confirmation that my router has not checked for updates since installing beta3, as expected.

Interestingly, I learned by accident that navigating to the AiMesh page triggers a firmware check. I don’t use AiMesh, but was heading to the Management tab to disable LEDs. Visited there 3x and the webs_update.sh script is called directly.

Aug  1 13:30:33 rc_service: cfg_server 2846:notify_rc stop_fw_check
Aug  1 13:30:34 rc_service: cfg_server 2846:notify_rc start_fw_check
Aug  1 13:32:03 rc_service: cfg_server 2846:notify_rc stop_fw_check
Aug  1 13:32:04 rc_service: cfg_server 2846:notify_rc start_fw_check
Aug  1 13:32:44 rc_service: cfg_server 2846:notify_rc stop_fw_check
Aug  1 13:32:45 rc_service: cfg_server 2846:notify_rc start_fw_check

https://github.com/RMerl/asuswrt-merlin.ng/blob/412958f30f18da5522fa672f8d4f08718ba6a2e1/release/src/router/rc/services.c#L25827

 

[Howard_inGA]

Dirty upgrade to 3006.102.5_beta3. It is running hot, straight, and normal...

 

[maxbraketorque]

Went from 102.5a2 to 102.5b3 this morning. No issues so far with my main/AP GT-AX6000 combo.

 

[Wisiwyg]

All, quick report... I've attempted to add a RP-BE58 to the 102.4 release without luck. https://www.snbforums.com/threads/asuswrt-merlin-3006-102-4-is-now-available.94651/post-957603 My RP-AX58 worked fine. I've continued to attempt to add the BE58 without luck through all the Beta cycles of 102.5 thus far. I intend to factory reset, then attempt to add the BE58 to the 102.5 branch on full release to my BE-96U main, prior to any customizations that I have installed, which are quite a few. I'll report status then. Good weekend, all.

 

[NightOwl3261]

One minor issue switching to latest version Merlin from OEM. RBG lighting showed a graphic that matched the lighting on router so one could see the end result of the scene you choose. On Merlin it just flashes colors.

 

[NightOwl3261]

Meant to mention: it's on a GT-BE98 pro

 

[Dedel66]

Meant to mention: it's on a GT-BE98 pro

Just add a short signature so everyone can see your setup that you're referring to.

 

[RMerlin]

Interestingly, I learned by accident that navigating to the AiMesh page triggers a firmware check. I don’t use AiMesh, but was heading to the Management tab to disable LEDs. Visited there 3x and the webs_update.sh script is called directly.

Aug  1 13:30:33 rc_service: cfg_server 2846:notify_rc stop_fw_check
Aug  1 13:30:34 rc_service: cfg_server 2846:notify_rc start_fw_check
Aug  1 13:32:03 rc_service: cfg_server 2846:notify_rc stop_fw_check
Aug  1 13:32:04 rc_service: cfg_server 2846:notify_rc start_fw_check
Aug  1 13:32:44 rc_service: cfg_server 2846:notify_rc stop_fw_check
Aug  1 13:32:45 rc_service: cfg_server 2846:notify_rc start_fw_check

https://github.com/RMerl/asuswrt-merlin.ng/blob/412958f30f18da5522fa672f8d4f08718ba6a2e1/release/src/router/rc/services.c#L25827

start_fw_check() calls are done from cfg_client and cfg_server, the components of AiMesh. I'd rather not interfere with either of them as I don't know what's behind that code. For instance they may expect the result from the script to be present after the calls.

 

[Analog-1]

Can we move on to a final release at this point ?

 

[ExtremeFiretop]

Can we move on to a final release at this point ?

Are you in a rush to get anywhere?
Patience is a virtue friend. Hold tight until everything is ready and solid.

Sounds like beta3 is petty much at the finish line, and just validating no new reports.

 

[Analog-1]

Are you in a rush to get anywhere?
Patience is a virtue friend. Hold tight until everything is ready and solid.

Sounds like beta3 is petty much at the finish line, and just validating no new reports.

I have been patient. It is what it is. I was just asking.

 

[ExtremeFiretop]

I have been patient. It is what it is. I was just asking.

And your absolutely allowed to ask. I was just answering haha I'm sure RMerlin is on the edge of doing a final release based on his wording that he "decided to have another short beta round."

I decided to have another short beta round.

If your simply itching for the latest release because your ready and everything is working for you. May I recommend installing MerlinAU and just forget about checking the forums until you get notifications the update was auto-installed?

Just a suggestion so you don't have to keep a tab open on SNB and monitor daily.

 

[Analog-1]

so you don't have to keep a tab open on SNB and monitor daily.

LOL. I do not monitor this forum daily. My issue is today is the only day i have enough free time to install and reconfigure a new release that's all. Like i said just asking. not the end of the world.