What's new

[ 386.7 alpha Build(s) ] Testing available build(s)

  • 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!

Did you brick your RT-AX86U when upgrading to 386.7 Alpha1


  • Total voters
    26
  • Poll closed .
Status
Not open for further replies.
The router WebUI interface only binds to ipv4. You can determine this by, netstat -nlp | grep lighttpd Notice that it only binds to tcp and not tcp6, where as your Nas probably binds to both tcp and tcp6 which is why you can access its interface over ipv6
That's too bad the router can't be accessed using ipv6. It is very difficult for us to obtain the public network IPv4 here.
 
We're on different routers, but both on 386.7 Alpha releases... I have no issues at all with IPv6. All aspects of IPv6 work for me, without any faults or errors (internal / external / tested and verified) so the issues might be specific to your router & this specific release? No doubt other users will confirm or deny this soon.
I have discussed this issue in the asus router exchange group in our place. It is impossible to access the webUI through ipv6, and the port forwarding settings are also ineffective.
 
I have discussed this issue in the asus router exchange group in our place. It is impossible to access the webUI through ipv6, and the port forwarding settings are also ineffective.
You can access it over ipv6 if your set it to be wan facing, otherwise the connection gets dropped. It looks more like poor firewalling with iptables.
 
The router WebUI interface only binds to ipv4. You can determine this by, netstat -nlp | grep lighttpd Notice that it only binds to tcp and not tcp6, where as your Nas probably binds to both tcp and tcp6 which is why you can access its interface over ipv6
I tried the method you said, and the router does not listen to the IPv6 protocol. There is a monitor in the nas, it seems that we can only wait for @RMerlin to fix this problem.
 
Are you disabling it through the global LED disable (on the System page) or only the Aura RGB itself (on the Aura tab)?
I see it was enabled on the Aura tab
1654518675551.png



Disable LED is set to No
1654518571457.png
 
@octopus :

Your poll is incorrect, you are assigning 10% to each vote???

As it stands now, the poll adds up to 80 + 30 +10 = 120%
 
Last edited:
@DJones
In Your Post you scheduled a router reboot for everyday. Is that necessary and why?

*Alpha fw surviving without any issues, since uploaded.
 
and the port forwarding settings are also ineffective.
Port Forwarding is for NAT, and IPv6 does not use NAT, it's a routed protocol. What you need is to open the ports on the router's firewall as well as on the client's firewall.
 
Port Forwarding is for NAT, and IPv6 does not use NAT, it's a routed protocol. What you need is to open the ports on the router's firewall as well as on the client's firewall.
Correct it will use the ipv6 input and/or forwarding tables if it is done correctly. This requires using the firewall table for ipv6 inside the gui. I have to use it for accessing wireguard on clients over ipv6.

@qiuyan81

Here is a specific example.

1654556618550.png
 
Last edited:
Successful installation and initial few hours of operation of 386.7_a1 on AC86U main/AP combo with relatively simple settings. Running time server, two OVPN clients, one OVPN server, manual DHCP assignments, parental control time limits, and some port forwarding.
 
1654535912368.png


At the risk of tempting fate but my AC68U node has been up 8d now with the New Alpha 1 and its wifi blob.
 
The purpose of this Alpha is testing, no?
You won't be able to see and report a bug, if the issue happens in >24h period.
I’m aware. One issue at a time rebooting each day let me catch this issue with aura.

Honestly overall not that concerned with testing this round, but as to why I flashed a alpha well I like to live on the fringes of latest updates. That said will try to monitor longer uptime stability as 24h periods it’s stable no wifi disconnects or any concerning system logs.
 
Last edited:
I have discussed this issue in the asus router exchange group in our place. It is impossible to access the webUI through ipv6, and the port forwarding settings are also ineffective.
Referring back to part of my previous post (which isn't exactly the same as your requirement, but...)
~~
Ironically, I haven't made any necessary edit, to allow access to my router's WebUI interface via IPv6, but purely because... currently, No IP provide a One Year Trustcor Standard DV SSL Certificate, which is included FOC for all of their DDNS Accounts. So using this, it's very easy to then access my router via my FQDN (No IP DDNS Name) via IPv4 and https, having made an edit, as described in this very helpful post
~~
I was also mindful of this later post by @SomeWhereOverTheRainBow so FWIW I did edit the content of the /jffs/configs/hosts.add file to exclusively use, only, the current IPv6 address of the router...

Having then rebooted everything / cleared all caches / cookies etc I could then very easily connect to my router i.e. the webUI, in any browser, via IPv6 using my FQDN aka - using my No IP (IPv6) DDNS Name. I monitored this specifically, in Wireshark, to confirm it was via IPv6. Having got proof of concept, I reverted the content of the /jffs/configs/hosts.add file back to IPv4 only, for the very reason stated in the later part of my previous post (not shown above) i.e. router reboots & IPv6 stateless addresses etc.

So, I stand by what I said in my first post on this: I have no issues at all with IPv6 on this Alpha release.
 
Netstat;

When I go to netstat, there is only one standard menu in the drop down, to my knowledge I’m missing the second more detailed one, or I’m missing something in former releases?

RT-AC86U.
 
So I switched the Aura RGB Enable to off. The Aura LED is off.
I had to reboot today (turns out it was my internet that was down), but after reboot, the Aura RBG was toggled back to enabled.

Disable LED is still set to No.
Disable LED set to Yes reads as "Yes, disable the leds.", while Disable LED set to No reads as "No, do not disable the leds.", but I don't know if this applies to aura rgb leds as I have no experience with it; so try it for yourself, set Disable LED to Yes in Administration - System and press Apply button, then reboot the router using a method that reenabled the leds previously.

1654606853072.png

Happy marching to 10 days uptime with RT-AC68U using latest 386.7 alpha after approximately one week free of problems with the first one. Good job and thank you @RMerlin.

Also I can access the WebUI using IPv6 as I can access it using IPv4, meaning using the IP addresses of the br0 interface, but in the internet browser address field, the IPv6 address has to be encapsulated by square brackets [ ] because the four hexadecimal delimiting character in the IPv6 address (human friendly) representation is the colon : , same as the one used to delimiting the port from the ip. So while for IPv4 the address is https://192.168.0.1:8443, for IPv6 the address is https://[fe80::aaaa:bbbb:cccc:dddd]:8443. This is the Link-local IPv6 address, but it works with the Global IPv6 one as well.
I've tested with Mozilla Firefox 101.0, Vivaldi 5.3.2679.38 (which is based on Chromium) and Internet Explorer 11.
 
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