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

[Swistheater]

I did. My own RT-AX86U is running fine, which is why I uploaded this alpha build.

@RMerlin mine flashed fine as well.

 

[AntonK]

I did. My own RT-AX86U is running fine, which is why I uploaded this alpha build.

.

Alpha build for AX86U? I don't see that on your Test Builds repository.

 

[SomeWhereOverTheRainBow]

Alpha build for AX86U? I don't see that on your Test Builds repository.

He must have pulled it. It appears 2 out of 8 users reported failed or bricked routers after flashing.

Apparently @dave14305 is the Jack of all trades.....

 

[RMerlin]

Asus are still investigating on their end. As part of their investigation they are trying to obtain more information, such as the serial numbers and MAC addresses of affected routers, which will help them figure out why only certain routers are affected. Could be a revision-specific issue for instance. I've already reached out to the two reported cases to obtain this info from them.

Asus has provided me more info which might allow me to release a safer build of the RT-AX86U (I'm waiting for a confirmation before I issue the tweaked build). In the meantime the current build was indeed pulled off the Onedrive folder.

 

[RMerlin]

Let's hope that Asus resolves the firmware for this model AND FULLY TESTS it

What more are you expecting me to test? I flashed it on my own router and it worked fine. I cannot flash test 10 different hardware revisions, I have only one single RT-AX86U.

 

[SomeWhereOverTheRainBow]

Asus are still investigating on their end. As part of their investigation they are trying to obtain more information, such as the serial numbers and MAC addresses of affected routers, which will help them figure out why only certain routers are affected. Could be a revision-specific issue for instance. I've already reached out to the two reported cases to obtain this info from them.

Asus has provided me more info which might allow me to release a safer build of the RT-AX86U (I'm waiting for a confirmation before I issue the tweaked build). In the meantime the current build was indeed pulled off the Onedrive folder.

It is nice to know you are at work in the thick of it all for now. I hope they manage to provide you with whatever you need.

 

[RMerlin]

The router WebUI interface only binds to ipv4.

Asus changed that recently, it should now listen to IPv6 as well.

You can determine this by, netstat -nlp | grep lighttpd

lighttpd is used by AiCloud, not by the management UI. That one is the httpd (and httpds) process.

 

[SomeWhereOverTheRainBow]

Asus changed that recently, it should now listen to IPv6 as well.


lighttpd is used by AiCloud, not by the management UI. That one is the httpd (and httpds) process.

RT-AX88U-C7C0:/tmp/home/root# netstat -nlp | grep httpd
tcp        0      0 0.0.0.0:9443            0.0.0.0:*               LISTEN      2611/lighttpd
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      21862/httpd
tcp        0      0 192.168.1.1:8080        0.0.0.0:*               LISTEN      21862/httpd
tcp        0      0 0.0.0.0:8082            0.0.0.0:*               LISTEN      2611/lighttpd
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      21861/httpds
tcp        0      0 192.168.1.1:8443        0.0.0.0:*               LISTEN      21861/httpds
tcp        0      0 :::8080                 :::*                    LISTEN      21862/httpd
tcp        0      0 :::8443                 :::*                    LISTEN      21861/httpds

none of them are TCP6 but it claims to be listening on "::"

here is an example from a RPI with lighttpd

RPI1:~# netstat -nlp | grep httpd
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      933/lighttpd
tcp6       0      0 :::80                   :::*                    LISTEN      933/lighttpd

Maybe the router OS does not distinguish between the two.

 

[RMerlin]

Maybe the router OS does not distinguish between the two.

It's possible that the busybox netstat applet doesn't explicitly report tcp6. httpd does have explicit code to handle IPv6 (tho I cannot say if the code is finalized - I can't test it easily).

initialize_listen_socket(int family, usockaddr* usa, const char *ifname)
{
        struct ifreq ifr;
        int fd;

        memset(usa, 0, sizeof(usockaddr));
        usa->sa.sa_family = family;
        switch (family) {
        case AF_INET:
                usa->sa_in.sin_addr.s_addr = htonl(INADDR_ANY);
                usa->sa_in.sin_port = htons(http_port);
                usa->sa_len = sizeof(usa->sa_in);
                break;
#ifdef RTCONFIG_IPV6
        case AF_INET6:
                usa->sa_in6.sin6_addr = in6addr_any;
                usa->sa_in6.sin6_port = htons(http_port);
                usa->sa_len = sizeof(usa->sa_in6);
                break;
#endif
        default:
                return -1;
        }

 

[Striker317]

GT-AX11000 dirty update seems stable only encountered issue is Aura RGB reenables itself after scheduled reboot despite previously disabling either through settings or button prior to the device rebooting.

Confirmed for me too re: Aura RGB reenabling itself after reboot (scheduled or forced). Off prior to reboot, enabled after reboot. GT-AX11000 running GT-AX11000_386.7_alpha1-g8ee6420ea6_cferom_ubi.w

 

[RMerlin]

Confirmed for me too re: Aura RGB reenabling itself after reboot (scheduled or forced). Off prior to reboot, enabled after reboot. GT-AX11000 running GT-AX11000_386.7_alpha1-g8ee6420ea6_cferom_ubi.w

Are you disabling it through the global LED disable (on the System page) or only the Aura RGB itself (on the Aura tab)?

 

[kernol]

What more are you expecting me to test? I flashed it on my own router and it worked fine. I cannot flash test 10 different hardware revisions, I have only one single RT-AX86U.

Chill ... No one has blamed you for the bricking - least of all me ... my plea was directed to ASUS who must remain responsible for their own GPL and have the resources (and responsibility) to thoroughly test their firmware BEFORE providing same to you or the public at large.

 

[learning_curve]

RT-AX88U-C7C0:/tmp/home/root# netstat -nlp | grep httpd
tcp        0      0 0.0.0.0:9443            0.0.0.0:*               LISTEN      2611/lighttpd
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      21862/httpd
tcp        0      0 192.168.1.1:8080        0.0.0.0:*               LISTEN      21862/httpd
tcp        0      0 0.0.0.0:8082            0.0.0.0:*               LISTEN      2611/lighttpd
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      21861/httpds
tcp        0      0 192.168.1.1:8443        0.0.0.0:*               LISTEN      21861/httpds
tcp        0      0 :::8080                 :::*                    LISTEN      21862/httpd
tcp        0      0 :::8443                 :::*                    LISTEN      21861/httpds

Different different router/setups etc but FWIW on the router/setup that I have, it's now this (expected):

**/tmp/home/root# netstat -nlp | grep httpd
tcp        0      0 127.0.0.1:80            0.0.0.0:*               LISTEN      670/httpd
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      669/httpds
tcp        0      0 192.168.1.1:8443        0.0.0.0:*               LISTEN      669/httpds
tcp        0      0 :::8443                 :::*                    LISTEN      669/httpds   
**/tmp/home/root#

Plus to confirm a previous post that I made in this thread, so far, there's been no unexpected issues at all for me (with IPv6) on this Alpha firmware release from @RMerlin

I can externally & internally ping6 the router's IPv6 address ( > IPv6 Enable Router Advertisement - Enable)

I can see that the Asus IPv6 DDNS Name functionality has still not been re-enabled in this specific firmware release, but that was also expected. I can still successfully (independently) DNS (DDNS) Check my IPv4 *.asuscomm.com name anyway & run any number of successful dig queries on this too. So that's all good.

I can also, still successfully (independently) DNS (DDNS) Check my *both of my No IP IPv4 and IPv6 DDNS names and I can run any number of successful dig queries on both of these addresses too. Again, all good.

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

Even more so, because unlike the router's IPv4 address (which is static), the router's IPv6 address does change on every re-boot, 'cos it's a stateless IPv6 address taken from the main /64 IPv6 static address, that's given by my ISP. Much as I'm keen to run IPV6 everywhere possible, It seemed overkill in this case.

 

[DJones]

Are you disabling it through the global LED disable (on the System page) or only the Aura RGB itself (on the Aura tab)?

For me the issue with aura rgb turning back on only occurs after a scheduled reboot and does not occur during a software reboot.

 

[jack ryan]

I did just have this after about 4 days of no issues. 5G channels didn't want to connect at all; a quick restart and it all came up again

it happened to me as well.

 

[RMerlin]

Chill ... No one has blamed you for the bricking - least of all me ... my plea was directed to ASUS who must remain responsible for their own GPL and have the resources (and responsibility) to thoroughly test their firmware BEFORE providing same to you or the public at large.

My misunderstanding then, I thought you were talking about my provided builds.

 

[HeadBanger]

I flashed two AX86U nodes at the weekend before I read about the potential bricking. Fortunately, both flashed without issue and seem to be running fine.

HB

 

[heslo]

it happened to me as well.

Very odd; mine has been fine since the full reboot. Hopefully it stays that way

 

[SomeWhereOverTheRainBow]

It's possible that the busybox netstat applet doesn't explicitly report tcp6. httpd does have explicit code to handle IPv6 (tho I cannot say if the code is finalized - I can't test it easily).

initialize_listen_socket(int family, usockaddr* usa, const char *ifname)
{
        struct ifreq ifr;
        int fd;

        memset(usa, 0, sizeof(usockaddr));
        usa->sa.sa_family = family;
        switch (family) {
        case AF_INET:
                usa->sa_in.sin_addr.s_addr = htonl(INADDR_ANY);
                usa->sa_in.sin_port = htons(http_port);
                usa->sa_len = sizeof(usa->sa_in);
                break;
#ifdef RTCONFIG_IPV6
        case AF_INET6:
                usa->sa_in6.sin6_addr = in6addr_any;
                usa->sa_in6.sin6_port = htons(http_port);
                usa->sa_len = sizeof(usa->sa_in6);
                break;
#endif
        default:
                return -1;
        }

It looks promising. In a couple of days, I will roll up my sleeves and do some testing.

 

[DiGz_Au]

damn, how many revisions do asus have of the ax86*, missed out on testing this alpha but the broken stock firmware worked for me. hope to see a revised build shortly.