Fixes and Improvements - #603
Conversation
- Fixed bug due to restarting the HTTP daemon right before starting to flash the F/W image. This was causing the previously authenticated login session token/cookie to become invalid. - Modified and improved functions used to login to the primary router and AiMesh nodes. - Added code to double-check that the current login session token/cookie is still valid before proceeding to flash the F/W image. If it's not valid, a 2nd login is attempted. If that fails, the router is rebooted to make sure the router goes back to a fresh state. - Miscellaneous improvements and fine-tuning.
|
When you get a chance, please review and validate the changes in this PR. I found a bug introduced in PR #601 where the code was restarting the HTTP daemon right before starting the F/W flash. All other changes are to improve the code and add more error checking and handling. Talk to you later, bud. |
| [ -z "$httpStatusSTR" ] && [ -s "$responseFPath" ] | ||
| then | ||
| ## MUST check & verify *IF* this is TRUE for AiMesh Nodes ## | ||
| if ! grep -qE 'url=index[.]asp|url=GameDashboard[.]asp' "$responseFPath" |
There was a problem hiding this comment.
When you get a chance to test and validate this PR code on your AiMesh nodes, please pay special attention to the above line #5535 with the if statement. I'm not sure if AiMesh nodes respond the same way as a primary router when a WebUI administration login is performed. If not, the above line will need to be modified,
Have a good one, bud!!
|
Yeah your right on this one 😅 I moved the but I ended up with: which risks invalidating the session I had just created. Overall I think this PR is good and I’m going to merge it in tonight! I think the additional logging for the future is a smart call. I did spot what looks like one small bug around the new temp files used during the parallel AiMesh node checks. I don’t think that needs to hold this PR up though. I’ll merge this as-is and address that separately in a small follow-up PR so we keep the fix focused and easy to review. This is FUN! The most fun we have had in a bit ;) Thanks for catching the session ordering issue, happy SOMEBODY is keeping me honest and testing my work ;) Apparently 2AM me should not be trusted with firmware flashing ordering 😄 |
|
Btw did you notice, we may end up needing to pivot the project at some point down the line? We are fine for the current WiFi 7 and BE models, but not WiFi 8 models going forwards. |
Great catch, bud!!!! I just submitted another PR to address this issue.
Yeah, it certainly is a very interesting set of events. Normally, this would not happen during the automatic F/W updates since they are separated by 15 minutes (between nodes and primary router), so while an edge case, it could happen "out in the wild" to some unexpected user doing manual F/W updates.
LOL!!! No worries, bud. It happens to the best of us. That's why we have each other's backs. |
Yeah, I briefly saw the post title, but I didn't have time to read the actual posts until the past weekend. But ultimately, if the hobby project is becoming a chore and no longer fun, it's time to hang up your hat. It's also probable that he wants to retire and enjoy some peace and quiet without worrying about merging another set of GPLs and making more F/W builds.
I suspect we might have only about 4 to 5 more years of future RMerlin F/W updates before he completely stops the project. At that point, the future of add-on development and support may be in limbo. Frankly, I'll likely move on and get a different router brand. I'm not going to spend close to $1K or more on an ASUS router that often seems to be under-developed, poorly tested, and barely passing QA standards (or ASUS is lowering their standards to be able to pass their own testing). Ubiquiti routers look very tempting. I also have a GL.iNet travel router that I always use to remotely connect back home when traveling for vacation or on work-related trips, so I may look more into their routers as well. And I've been reading about the Firewalla Gold Plus routers, which also look very promising. In any case, we'll see what happens, and where we are in the next 4-5 years, before any decisions are made. Take care, bud!! |
It's no problemo my friend, I have a node and I know what I'm looking for when testing the changes. "I can help guide us through the darkness" 😉 i had started working on my own PR. It's slightly different on the design but you submitted yours first so I just said forget it and merged yours instead. Mine would probably just have a different set of bugs, at least yours were easy typos mostly 😂
Agreed, it's not something that happens usually just due to the fact they should be staggered when ran automatically. But as you pointed out and I found it, if triggered manually on both within a short timeframe, you can run into this and go "what the heck happened? The node said it was flashing, then rebooted but didn't update?" It's why I figured this is both an interesting challenge for us to tackle and if we succeed it's one less edge case to address. I think we are on the right track to closing this vulnerable window for the nodes.
I got your back, you got my back, together, we pump out something that works how we intended it would 😉 |
I used to run a pfsense router I built myself long ago, had even patched the kernel using some steps I found online. It was fun back then, but I ended up going to a more consumer product hoping to have less issues. I ended up deep in the rabbit hole here with you 😂 funny how that is eh. But like you said there's lots of other good router options out there... Nothing forces me to stay, I already struggles to swallow the purchase of the BE98 Pro. I'll probably hold on to my WiFi 7 setup with ASUS as long as I can, I don't see a rush to move anytime soon when barely any of my devices (only a handful) are WiFi 7 and 6GHz capable today. But we should start thinking about what the future path will be for us. I hope to continue working with you in some capacity here and there, even if we end up on different product lines. It's been fun over the years working with you back and forth on stuff and getting to know you as a person. |
My first ASUS router was the RT-AC68U. It was a solid device, and once I found the RMerlin's F/W available, I was even more impressed with all the customization I could do. That was followed by the RT-AC86U and now the RT-AX86U_PRO. All very good routers at a very good, reasonable price. The RT-AC86U has the "stuck nvram command" issue (for which I wrote a custom script to work around the problem); but otherwise, it served me well for many years, and is still going strong now as an AP, or as a double-NAT router used for add-on testing & development purposes. But now, IMO, the newer BE-class ASUS routers are unreasonably more expensive, while the quality and robustness of the F/W have not improved or increased along the way. This is no longer acceptable in my book.
Yeah, perhaps we could collaborate on some other projects; but if we end up using different router brands/platforms, it would make it much more difficult to work together since we couldn't test and validate the application on the intended H/W and F/W platform unless it works on both!! But as mentioned before, no hard decisions can really be made at this point. We'll see where we are in 3 to 5 years. In the meantime, let's continue on this journey and have fun with this project and with RMerlin's F/W while we can. Take care and have a good night, bud!!! |
2 participants
Fixed bug due to restarting the HTTP daemon right before starting to flash the F/W image. This was causing the previously authenticated login session token/cookie to become invalid.
Modified and improved functions used to login to the primary router and AiMesh nodes.
Added code to double-check that the current login session token/cookie is still valid before proceeding to flash the F/W image. If it's not valid, a 2nd login is attempted. If that fails, the router is rebooted to make sure the router goes back to a fresh state.
Miscellaneous improvements and fine-tuning.