What's new

Beta Asuswrt-Merlin 386.7 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.
Reboot tab won't reboot the router when pressed, but this is not new to 386.7 beta. It had happened to me for a long time, I lost track of which version it started.
Something's weird with the Reboot button. What I noticed is sometimes, nothing seems to happen, yet the router will still reboot, it just won't show the rebooting wait page, or it will show it only after like a minute. In my test it seemed to mostly happen when using HTTPS and a self-signed certificate.
 
Dirty flash of B2 over B1 on my two RT-AX88U APs. No issues off the hop - devices all re-connected, IOT/Nest/TP-Link etc.... Will go through the usual reboots at 15mins and 60mins and then let it ride.
 
Updated the AXE11000 to B2 from B1 (save, format JFFS and restore JFFS) and downstream AiMesh units. Nothing weird (to me) in Syslog and all Add-Ons running ok. Great way to start the weekend for me and the family! Thanks @RMerlin
 
Last edited:
at this point i think i'd need a flamethrower to kill the wifi at home.
Put on some popcorn in the microwave. That might do it, tho here I have a Roomba parked right next to my microwave, and it still keeps its 2.4 GHz connection to the router at the other end of the apartment :)
 
Hi, Just like to report that I have successfully flashed 386.7_beta2 (GPL:386_48966) over 386.7_beta1 for my AiMesh setup:
  • AiMesh Router: AX88U 386.7_beta2
  • 2 x AiMesh Nodes: AX86S 386.7_beta2, AC86U 386.7_beta2
Thanks!
 
@RMerlin I can bring closure to the $PATH mystery that @jsbeddow was having earlier on in this thread.

We get smarter every day. I just installed SmarTTY that jsbeddow was using and found the following:
Code:
tlc@172.18.0.1:2222:/$ echo $PATH
/usr/sbin:/usr/bin:/sbin:/bin
tlc@172.18.0.1:2222:/$ which sh
/usr/sbin/sh
tlc@172.18.0.1:2222:/$ /usr/sbin/sh --help
/usr/sbin/sh: unrecognized option '--help'
Error: Invalid switch

*** Usage:
 dw/dh/db <physical address in hex> <number>
 dw/dh/db <-k> <virtual address in hex> <number>
 sw/sh/sb <physical address in hex> <data value1> <data value2> ..<data valueN>
 sw/sh/sb <-k> <virtual address in hex> <data value1> <data value2> ..<data valueN>
 fw/fh/fb  <physical address in hex> <data value> <length>
 fw/fh/fb <-k> <virtual address in hex> <data value> <length>
  -s (currently works with physical addresses for d*/s*/f* commands
and virtual addresses for s*/f* commands)

This confirms that SmarTTY is using their own $PATH environment when using their "Smart Terminal" option instead of the "Normal Terminal" option in the settings.

Kids, DO NOT USE SMART DEVICES, use your brain instead :cool: ;). And stay the f$ck away from the app called SmartTTY. Use MobaXTerm, or better still, Xshell from Netsarang.
 
Hmmm...looks familiar? Functionally, things are just fine:

Code:
Jun 17 20:51:37 kernel: potentially unexpected fatal signal 11.
Jun 17 20:51:37 kernel: CPU: 1 PID: 3821 Comm: dcd Tainted: P           O      4.19.183 #1
Jun 17 20:51:37 kernel: Hardware name: GTAX6000_50991 (DT)
Jun 17 20:51:37 kernel: pstate: 80030010 (Nzcv q A32 LE aif)
Jun 17 20:51:37 kernel: pc : 000000000002a110
Jun 17 20:51:37 kernel: lr : 000000000002a2ac
Jun 17 20:51:37 kernel: sp : 00000000ffb06670
Jun 17 20:51:37 kernel: x12: 00000000000a3120
Jun 17 20:51:37 kernel: x11: 00000000f65fd480 x10: 0000000000083794
Jun 17 20:51:37 kernel: x9 : 0000000000000000 x8 : 0000000000000003
Jun 17 20:51:37 kernel: x7 : 0000000000000021 x6 : 00000000f65fd39c
Jun 17 20:51:37 kernel: x5 : 0000000000000036 x4 : 00000000000001eb
Jun 17 20:51:37 kernel: x3 : 0000000000000000 x2 : 00000000f65fd480
Jun 17 20:51:37 kernel: x1 : 0000000000000012 x0 : 0000000000000000
 
Hmmm...looks familiar? Functionally, things are just fine:

Code:
Jun 17 20:51:37 kernel: potentially unexpected fatal signal 11.
Jun 17 20:51:37 kernel: CPU: 1 PID: 3821 Comm: dcd Tainted: P           O      4.19.183 #1
Jun 17 20:51:37 kernel: Hardware name: GTAX6000_50991 (DT)
Jun 17 20:51:37 kernel: pstate: 80030010 (Nzcv q A32 LE aif)
Jun 17 20:51:37 kernel: pc : 000000000002a110
Jun 17 20:51:37 kernel: lr : 000000000002a2ac
Jun 17 20:51:37 kernel: sp : 00000000ffb06670
Jun 17 20:51:37 kernel: x12: 00000000000a3120
Jun 17 20:51:37 kernel: x11: 00000000f65fd480 x10: 0000000000083794
Jun 17 20:51:37 kernel: x9 : 0000000000000000 x8 : 0000000000000003
Jun 17 20:51:37 kernel: x7 : 0000000000000021 x6 : 00000000f65fd39c
Jun 17 20:51:37 kernel: x5 : 0000000000000036 x4 : 00000000000001eb
Jun 17 20:51:37 kernel: x3 : 0000000000000000 x2 : 00000000f65fd480
Jun 17 20:51:37 kernel: x1 : 0000000000000012 x0 : 0000000000000000
Yup, is just Trendmicro & Pixelserv having a disagreement.
As you say, everything works ok, just log clutter?:)
 
Dirty flashed from the previous beta_1 on to the latest beta_2 firmware release.
All running perfectly for me so far. Thanks again @RMerlin for everything to date.
 
So, one bit of weirdness persists in this latest:
'The last 4 updates to the software have prevented accessing the modem through the router at address: 192.168.100.1 This address had been easily accessible without the need to hardwire the computer to the modem to do so. If I go through that flail, then the modem gui logs in normally without a hitch? With the router factory reset as described, it still refuses to resolve this address and connect to the gui?'
Any ideas on this one??
 
Thanks for Beta 2... Followed the recommended path "Backup JFFS->Flash Beta 2->Reformat JFFS->Reboot->Restore JFFS->Reboot" and everything went smooth.
Best of all, the "CONSOLE:" spamming in the log is gone!! :p
Code:
8fe761e94a HND5.02L07p2: replace dhd with build without debug enabled for RT-AX86U and GT-AXE11000
 
flashing with a USB disk plugged is not a problem. It's just that if you actively use SMB sharing with that disk and your router's RAM is used for caching, then sometimes flashing may fail due to not having enough free RAM.
I don’t use SMB, but flashes on my AC86u regularly fail when the USB flash drive is plugged.

Any other known memory hoarders?
 
You guys keep default ip range ? i just use 10.0.10.1

Yeah, easier to go with the flow than to remember to change the router's IP address after every factory reset *smile*.
 
Last edited:
So, one bit of weirdness persists in this latest:
'The last 4 updates to the software have prevented accessing the modem through the router at address: 192.168.100.1 This address had been easily accessible without the need to hardwire the computer to the modem to do so. If I go through that flail, then the modem gui logs in normally without a hitch? With the router factory reset as described, it still refuses to resolve this address and connect to the gui?'
Any ideas on this one??
Not seen this on my RT-AX88U. Can access the Virgin Media modem on 192.168.100.1 just fine. Is your network mask set correctly for your LAN (i.e. 255.255.255.0)? What's your LAN IP range?
 
3x RT-AX86U upgraded from Beta 1 to Beta 2 (didn't use alphas this time due to nervousness around Asus induced bricking issues in their code).

Two of them upgraded over WAN, and all three purchased at different times and not from same batch.

All upgraded OK and seem to be working.

Thanks Merlin :)
 
This morning i upgraded to beta2 my main router Ac86u and Ac68u (mesh) from the old 386.2_6 firmware, all it's fine.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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