[ISSUE][RT-AC56U][380.66] HTTPS webui unable to load and bootloop after factory reset

[bigeyes0x0]

So I have started testing both beta 5 from yesterday and currently having the same issue with the stable version as stated in the title with my RT-AC56U.

The https webui of the router either unable to load or take a very long time after boot to be responsive.

Also I found out that doing a software or hardware reset on this version of the firmware causes bootloop on my router until I apply a power cycle.

@RMerlin please help check these issues. I'm back to 380.65_4 for now and it's rock stable again.

 

[RMerlin]

The https webui of the router either unable to load or take a very long time after boot to be responsive.

Chrome and Asuswrt's httpd daemon never got along too well with HTTPS. No idea what the root cause is, all I can see is Chrome pegs the CPU for a few seconds as it gets stuck doing something.

 

[bigeyes0x0]

I don't use Chrome, the issue happens with both Edge and Firefox on 2 PCs both running Windows 10 Creators Update. During the time HTTPS webui being unresponsiveness, ssh and scp to the router still works normally.

The thing is, https unresponsiveness does not happen right away after upgrading. Only after I apply another setting to enable bridge mode multicast (as I need it for snooping my IPTV setup), or after I factory reset and apply https mode.

 

[thelonelycoder]

Does a restart of httpd work?
service restart_httpd

 

[bigeyes0x0]

I haven't tried that, but as I've lost an entire morning for this let do this later.

 

[thelonelycoder]

I haven't tried that, but as I've lost an entire morning for this let do this later.

If it works, add it to one of the jffs/scripts files, with a sleep delay.
This way the GUI will restart after reboot.

 

[Theliel]

Working perfectly for me on RT-AC56u, updated from 380.65 -> 380.66, https (443), W10 1703, FF + Chrome and IE.

Its true that Chrome take some extra secs the first time opening webui, but nothing more.

About bootloop, I have not done any reset for now.

 

[bigeyes0x0]

@thelonelycoder didn't work for me.

@RMerlin, I tried flashing new CFE 1.0.2.9 from 1.0.2.7 and the reboot loop now seems gone. In any case, the issue with https is still the same, even after I factory reset and only set a new password, switching to https causes the issue without anything plugged into the router saved for one PC.

 

[Adamm]

Maybe not the same issue, but I've noticed for awhile now that the GUI tends to time out loading some elements until a refresh. Not sure if this is of any help.

 

[MarcusVR]

I just downloaded the new firmware and, when trying to install, received a message:

Invalid Firmware Upload
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware.
​

RT AC88U, using 380.65.4.

 

[thelonelycoder]

I just downloaded the new firmware and, when trying to install, received a message:

Invalid Firmware Upload
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware.
​

RT AC88U, using 380.65.4.

Are you sure you downloaded the latest version?
Check again.

 

[MarcusVR]

Are you sure you downloaded the latest version?
Check again.

thelonelycoder, if you wanna call me dumb, you may!

I had downloaded the first file of the page, instead of the last, wich contains the newest version...

Thanks a lot, man!

 

[jack901]

I use a mozilla product and when I updated to 66 release it took a minute or two to get to the login via ip address. and after I reboot I always get a security warning and to make a new cert.
well went into browser prefs and checked certificates and I must of had 100 plus for that ip. deleted all but one and tried to get to the webui again and it was instant. do not know if your issue is the same but just throwing it out there. still do not understand why it would make a difference. or maybe it was something else that resolved itself.

I don't use Chrome, the issue happens with both Edge and Firefox on 2 PCs both running Windows 10 Creators Update. During the time HTTPS webui being unresponsiveness, ssh and scp to the router still works normally.

The thing is, https unresponsiveness does not happen right away after upgrading. Only after I apply another setting to enable bridge mode multicast (as I need it for snooping my IPTV setup), or after I factory reset and apply https mode.

 

[RMerlin]

well went into browser prefs and checked certificates and I must of had 100 plus for that ip. deleted all but one and tried to get to the webui again and it was instant.

That's interesting info, thanks. I wonder if that might be part of the reason why https in general feels so sluggish with Asuswrt.

I want to eventually make it easier to have a permanent certificate installed rather than having a new one constantly re-generated. Having a valid certificate generated since 380.66 laid some foundation toward improving upon SSL performance on this firmware.

 

[RMerlin]

The thing is, https unresponsiveness does not happen right away after upgrading. Only after I apply another setting to enable bridge mode multicast (as I need it for snooping my IPTV setup), or after I factory reset and apply https mode.

I would consider enabling EMF/IGMP snooping on the IPTV page rather than multicast_snooping, as it will be far more efficient than the broken bridge level snooping. Make sure you don't enable bridge snooping at the same time as EMF however, as the two will conflict.

 

[bigeyes0x0]

I would consider enabling EMF/IGMP snooping on the IPTV page rather than multicast_snooping, as it will be far more efficient than the broken bridge level snooping. Make sure you don't enable bridge snooping at the same time as EMF however, as the two will conflict.

I have tried EMF on IPTV page without bridge snooping but that didn't snoop any packet for my config thus I was having multicast storm in my network, still my config is not vanilla.
I use services-start script to set LAN ports to provide:
1 - internet untagged - iptv tagged trunked to a managed switch where I further split vlans.
2 - internet
3 - iptv untagged
4 - iptv untagged

This is the services- start file I use for that and enable snooping on my iptv vlan without EMF enabled in IPTV page

#!/bin/sh

# iptv stuffs
ID=`nvram get switch_wan1tagid`
[ -z "$ID" ] && exit 0

robocfg vlan $ID ports "0t 2 3 4t 5t"
robocfg vlan 1 ports "0 1 5t"
vconfig add eth0 $ID
ifconfig vlan$ID up
snooper -s vlan$ID

This script only work for AC56U and any router with same port and switch configuration of course.

I will retry 380.66 later but for now I'm tinkering with acme.sh script .

 

[bigeyes0x0]

Worked around it, using self sign cert from 380.65_4 works with 380.66.

acme.sh works really nicely on our router still I rather ssh to my router then remote control my router webui through tunnel without exposing the webui to wan so I keep using self signed cert from version 380.65_4 with 380.66. I will check if the cert generation issue or the firefox exception list is the issue later. For now considered the problem has been worked around.

 

[bigeyes0x0]

OK we can consider this issue a side effect of too many security exceptions for router IP. I had to reset my firefox installation to fix it though. It seems to cough up with too many exceptions for the old kind of cert the router used to make compared to the new one.