Firmware "Check Update" just spins and spins with no response

[Sas]

Oh I guess it was ok, because if I replace the O (oh) with a 0 (zero) it returns "Malware"

 

[Sas]

So, the question remains...why the spinning gif and no update check?

 

[dave14305]

wasn't this mitigated in 384.18? https://github.com/RMerl/asuswrt-merlin.ng/commit/8361d39aff247d79bd24a89d5e7f0607baddec27

Time flies...I thought it was staged for 384.19.

So, the question remains...why the spinning gif and no update check?

What happens in the GUI if you run this at the SSH level?

service start_sig_check

 

[Sas]

What happens in the GUI if you run this at the SSH level?

service start_sig_check

This happens:

RT-AC68U-2860:/tmp/home/root# service start_sig_check


Done.

 

[dave14305]

This happens:

RT-AC68U-2860:/tmp/home/root# service start_sig_check


Done.

Expected. What does the GUI show now?

 

[Sas]

Expected. What does the GUI show now?

Same...just the spinning gif. Which to be fair, is just an animated gif, it would always spin. But what I would expect is a message in the gui that it had checked and found nothing, or a window popping up with new version details, like it used to.

 

[dave14305]

Same...just the spinning gif. Which to be fair, is just an animated gif, it would always spin. But what I would expect is a message in the gui that it had checked and found nothing, or a window popping up with new version details, like it used to.

If you go back to the F12 Developer tools, do you still see the detect_firmware.asp being repeated? What is the response now, if different than before. This is what mine looks like:

webs_state_update = '1'; webs_state_error = '0'; webs_state_info = '384_18_0'; webs_state_info_beta = ''; webs_state_REQinfo = ''; webs_state_flag = '0'; webs_state_upgrade = ''; sig_state_flag = '0'; sig_state_update = '1'; sig_state_upgrade = '1'; sig_state_error = '0'; sig_ver = '2.186'; if(cfg_sync_support){ cfg_check = ''; cfg_upgrade = ''; }

So it would useful to also know what your nvram vars look like:

nvram show 2>/dev/null | grep -iE "^webs|^sig" | sort

 

[Sas]

Thanks for your help, I appreciate it!
The network panel of devtools just keeps endlessly repeating calls to detect_firmware.asp, ajax_onboarding.asp, and ajax_status.xml in a loop with differing timestamps appended.

detect_firmware.asp looks like this for me:

webs_state_update = '';
webs_state_error = '';
webs_state_info = '';
webs_state_info_beta = '384_10_beta3';
webs_state_REQinfo = '';
webs_state_flag = '0';
webs_state_upgrade = '';
sig_state_flag = '0';
sig_state_update = '1';
sig_state_upgrade = '';
sig_state_error = '0';
sig_ver = '';
if(cfg_sync_support){
cfg_check = '';
cfg_upgrade = '';
}

Here is the result of that command:

RT-AC68U-2860:/tmp/home/root# nvram show 2>/dev/null | grep -iE "^webs|^sig" | sort

sig_state_error=0

sig_state_flag=0

sig_state_info=2186

sig_state_update=1

sig_update_t=0

webs_last_info=

webs_notif_flag=

webs_state_error=

webs_state_flag=0

webs_state_info_beta=384_10_beta3

webs_state_update=

webs_state_upgrade=

webs_update_trigger=cfgsync_firmware_check

 

[AntonK]

Round and around the firmware check goes, where it stops, nobody knows.

 

[dave14305]

Thanks for your help, I appreciate it!
The network panel of devtools just keeps endlessly repeating calls to detect_firmware.asp, ajax_onboarding.asp, and ajax_status.xml in a loop with differing timestamps appended.

detect_firmware.asp looks like this for me:

webs_state_update = '';
webs_state_error = '';
webs_state_info = '';
webs_state_info_beta = '384_10_beta3';
webs_state_REQinfo = '';
webs_state_flag = '0';
webs_state_upgrade = '';
sig_state_flag = '0';
sig_state_update = '1';
sig_state_upgrade = '';
sig_state_error = '0';
sig_ver = '';
if(cfg_sync_support){
cfg_check = '';
cfg_upgrade = '';
}

Here is the result of that command:

RT-AC68U-2860:/tmp/home/root# nvram show 2>/dev/null | grep -iE "^webs|^sig" | sort
sig_state_error=0
sig_state_flag=0
sig_state_info=2186
sig_state_update=1
sig_update_t=0
webs_last_info=
webs_notif_flag=
webs_state_error=
webs_state_flag=0
webs_state_info_beta=384_10_beta3
webs_state_update=
webs_state_upgrade=
webs_update_trigger=cfgsync_firmware_check

So it seems like you're missing some nvram vars. Mine are below:

# nvram show 2>/dev/null | grep -iE "^webs|^sig" | sort
sig_state_error=0
sig_state_flag=0
sig_state_info=2186
sig_state_update=1
sig_state_upgrade=1
sig_type=FULL
sig_update_t=1594360984
webs_last_info=
webs_notif_flag=
webs_state_error=0
webs_state_flag=0
webs_state_info=3004_384_18_0
webs_state_info_am=384_18_0
webs_state_update=1
webs_state_url=
webs_update_trigger=

No one likes to hear this, but maybe you should reset to factory defaults and start fresh, in case other variables are missing or broken.

 

[Sas]

So it seems like you're missing some nvram vars. Mine are below:
No one likes to hear this, but maybe you should reset to factory defaults and start fresh, in case other variables are missing or broken.

So before I go down that route, are there any commands to set these values manually?

 

[dave14305]

So before I go down that route, are there any commands to set these values manually?

Make a backup first. Take the ones in my list but not in your list and prefix them with "nvram set". For example:

nvram set webs_state_info_am=384_18_0

After you've set all the ones missing, finish with:

nvram commit

Then try the update again. If things are worse than before, restore your settings backup.

 

[L&LD]

Check what’s in /tmp/webs_upgrade.log after pushing the update check button.
Then run

sh -x /usr/sbin/webs_update.sh

to see if the underlying script runs successfully and check the file again.

I'm unsure about running this command. When running it with '30' (three zero) should it say Malware or not? And if it does say Malware, does it mean the router is infected?

Thank you, things seem hard for me today.

 

[dave14305]

I'm unsure about running this command. When running it with '30' (three zero) should it say Malware or not? And if it does say Malware, does it mean the router is infected?

Thank you, things seem hard for me today.

If you change the test from 3O to 30 the results will be inverted. It was just a quick and dirty check.

 

[dave14305]

@Sas Sorry, I got confused and thought we were discussing the signature update check instead of the firmware update check.

So I will go back to my earlier request from May to post the output of this command (the actual firmware check script):

sh -x /usr/sbin/webs_update.sh

Eventually, someone will need to ask what model your router was assigned at birth (i.e. AC68U or Tee-Em-AC1900). It sounds like an oddity with the closed-source AiMesh cfg_sync components.

 

[Sas]

@Sas ...
Eventually, someone will need to ask what model your router was assigned at birth (i.e. AC68U or Tee-Em-AC1900). It sounds like an oddity with the closed-source AiMesh cfg_sync components.

I went through quite the odyssey trying to reset my router from scratch. My connected usb stick stopped working (permanently, I guess it was just its time to die), there were all kinds of entware and other software I had configured over the years, the backup I had made was somehow corrupt and would not reload, etc. And even after rebuilding the entire thing, it would STILL not check for updates. Since this router was long in the tooth anyway (and most importantly, I realized a converted "Tee-Em-AC1900" after you mentioned that), I decided to upgrade to a new RT-86U. It has been working flawlessly, is quite a bit faster, and the range is also better. Thanks for all of your help during this, I learned a lot about some of the inner workings of the software.

 

[Figaro]

Hi I have searched the forums but not found anything mentioning this particular problem. I'm on AC68U, currently with firmware 384.17. For the past 2 or three versions of the firmware (about 2 months I guess) whenever I go to the Firmware Upgrade page and click the "Check" button, I just get a spinning gif and the words:

Contacting the update server...

It just stays like this

Pardons if this has already been proposed.
I've had this issue with my AC86U and this is how I got around it.
I did a manual update of the firmware even if it was current. After that the check worked fine.