Update the Login Process and the Script Update Process for MerlinAU.sh#36
Update the Login Process and the Script Update Process for MerlinAU.sh#36ExtremeFiretop merged 12 commits intodevfrom
Conversation
|
Still remaining: On the AX88U Pro, it never completed the flash from script on the second run, the first run failed because I was logged into the web UI, the second run froze at "Flashing, please wait for reboot" and didn't reboot or do anything for 5+ minutes. Finally, I logged into the web UI, rebooted the router, and update had not completed. I'll be digging through the logs myself to see what happened. |
|
My only guess so far on the AX88U Pro is that it's file extension is different with: ".pkgtb" instead of a ".w" once extracted from the .zip |
|
Exactly what I thought the problem was. At lines ~1798 we specify the file type to find: "pure_file="$(ls | grep -iE '_pureubi.w|_ubi.w' | grep -iv 'rog')"" I think it's best we use a looser matching method which can work for all file types. |
|
Modified the grep match to include the new .pkgtb file type. |
|
So that change correctly flagged and selected the new .pkgtb file as found in the below logs: RT-AX88U_Pro_FW_Update_2023-12-17_15_32_02.log However, it still "froze" at the flashing step. In the logs at around 15:33 |
| # DEBUG: Print the LAN IP to ensure it's being set correctly | ||
| printf "\n**DEBUG**: Router Web URL is: ${routerURLstr}\n" | ||
|
|
||
| printf "${GRNct}**IMPORTANT**:${NOct}\nThe firmware flash is about to start.\n" |
There was a problem hiding this comment.
Moved this up from below. (where the routers login happens.)
| echo -e "${CYANct}Download successful!${NOct}" | ||
| echo -e "$(date) - $SCRIPT_NAME - Successfully downloaded $SCRIPT_NAME v$DLRepoVersion" | ||
| echo -e "${CYANct}Update successful! Restarting script...${NOct}" | ||
| exec "${ScriptsDirPath}/${SCRIPT_NAME}.sh" # Re-execute the updated script |
There was a problem hiding this comment.
This exec will relaunch the new version of the script at the end.
|
I couldn't reboot the router in the WebUI. Had to reboot it via ssh typing "reboot". |
|
WEIRD. Post reboot it was updated lol. It just didn't reboot itself? WEIRD. |
|
Extended the sleep from 60 seconds to 3 minutes to be "sure" the update is done. |
| -F "file=@${firmware_file}" \ | ||
| --cookie /tmp/cookie.txt > /tmp/upload_response.txt 2>&1 & | ||
| sleep 60 | ||
| sleep 180 |
There was a problem hiding this comment.
Extended the sleep timer from 60 to 180 (3 minutes, the default amount in the webUI when doing an upgrade) to be sure the update should be completed before we throw a reboot command.
| --cookie /tmp/cookie.txt > /tmp/upload_response.txt 2>&1 & | ||
| sleep 60 | ||
| sleep 180 | ||
| /sbin/service reboot |
There was a problem hiding this comment.
Adding a reboot for some routers after 3 minutes of waiting if it didn't reboot itself.
There was a problem hiding this comment.
I just had an idea to improve this crucial point in the process. Let me code it and run some testing before I put it in the script.
| # Detect ROG and pure firmware files | ||
| rog_file="$(ls | grep -i '_rog_')" | ||
| pure_file="$(ls | grep -iE '(_pureubi\.w|_ubi\.w|.*_nand_squashfs\.pkgtb)$' | grep -iv 'rog')" | ||
| pure_file="$(ls | grep -iE '(\.w|\.pkgtb|\.trx)$' | grep -iv 'rog')" |
There was a problem hiding this comment.
Only match by file extensions, and remove any found files with "rog" in the name.
|
I can confirm I got a successful upgrade on the AX88U Pro using these fixes. |
|
I also unblocked these routers:
Here: 0a8d58e As I never got a response from Yota in the forums, and I believe the changes in logic we've made for memory and requiring a USB on these models should technically allow for it to work. Until someone tests and provides logs that the latest dev build doesn't work, I will claim they are supported. |
|
However, that being said, I just noticed that the naming scheme for those routers firmware is different: https://sourceforge.net/projects/asuswrt-merlin/files/RT-AC68U/Release/ Makes me think maybe we would need to account for this since the actual flash right now uses the dotted version of the 3004 versioning right now for example. |
|
nvm. We say that the RT-AC86U works and it uses the same naming scheme so we already account for it: That is your model right? How does the flash work when it's using the dotted version of the firmware? |
|
Nvm. I got my answer, it dots the first octs of the release version no matter what it is. |
Excellent catch!! |
Yes, that's correct. The release versioning schemes & eventual comparison are handled via the functions GetCurrentFWInstalledShortVersion() & FWVersionStrToNum() which take into account the "old" and the "new" format. |
Excellent! It looks like you had a very productive day chasing the issues with AX88U Pro router. Good job buddy!! |
I had some free time today, and just wanted to add another model tested on the list, I realized my side gig had an AX88U Pro which I had access too, so I tested it expecting it to just work. When it didn't, it sent me down a rabbit hole of tweaks and fixes until it worked. I know this was lots to read, it was mostly taking notes for myself and my thought process while troubleshooting. Lol. The big take aways today was:
As usual if you notice anything I did was wrong or makes a bug please let me know. Your the master! |
|
Are you also confirming it's worked for you using the RT-AC86U? Is that your router too? (My friend has it) My friend is still using my old desktop script for now ... but I updated the desktop script to use this curl method so he's been happy with that until I convince him to migrate to this. |
That was some very nice sleuthing you did today, and it was a very serendipitous discovery with the AX88U Pro router, just in time before promoting the latest "Dev" version to the "Main" branch.
I'm starting to review the latest changes. It all looks good so far.
Will do. But I have not yet achieved the "master" status; it takes patience & perseverance, Grasshopper! P.S. I hope you get the reference to the TV show :>). |
Yes, I've run the full F/W update process only once, and it did work without any issues. I realize that one data sample is not too convincing, but I also run a "test/debug" version that I have which includes some carefully placed "printf" statements to stdout to display what's happening as it executes until the point just before the actual "curl" command that does the final update. |
Started to address known issues.
Script logins into the WebUI before the final prompt to continue.
(This has been resolved by moving the login sequence behind/after the final prompt)
Script update process does not relaunch the updated script.
(This was resolved by having the script re-execute itself into memory right after update.)