I don't want the AIMesh node on all the time, though. I only need it for one specific spot in my back yard, and the rest of the time it just emits unwanted warmth while using precious electricity. I can't imagine that the AiMesh couldn't handle the loss of a node anyway, it should by design be able to handle that (and it does appear to handle it just fine, in fact, save for the very problem I'm having).
On the topic of the AiMesh, I've noticed that the Mesh node doesn't broadcast the frontplane SSID sometimes after reboot of either the node or the router. In this situation, though, clients which are WIRED to the mesh node work fine. So it's effectively a client bridge unless I issue a reboot or power-cycle it. This happens a lot, actually, outside of the router reboot problem.
Also, here is where I will complain that the AiMesh doesn't actually do what I even wanted in the first place. I wanted to extend my GUEST network, but apparently it only extends the main 5Ghz one. That, to me, seems ... incomplete. I have read elsewhere that the Merlin firmware combined with some complex vlan and bridge interface config might help. I understand that conceptually, but I don't see anyone having proved this with the 2 specific devices I have. (Plus, I would prefer to stay on stock firmware, at least for now.)
Another observation is that when I bring up the UI for the mesh node in a browser, I just get a message like:
Unable to connect to the Parent AP.
RT-AC68R
We suggest you
- Ensure that your AiMesh router has been powered on.
- Reboot your AiMesh router and try again
(Which, is a totally bogus message. The fact that I can even render that message proves it can connect to the parent AP.)
That said, it does appear the mesh node takes certain config from the AP, because it accepts my SSH key and I can get command-line access. Anyway, w/r/t resetting the node, I'd have to go with the button or 30-30-30 method, I suppose.
So, on the subject of nightly reboots, yes, this was a bit of a quick-and-dirty mitigation/tiptoeing step. I wanted to see if the issue occurs if I reboot nightly. I'm significantly less concerned about hardware toll and the like, it seems (like, not at all concerned). I'd eventually move to weekly or 3x-weekly or something anyway, if needed. The thing about reboots is, I can tolerate 1 reboot a day, if I can control when it happens. What I don't like is the randomness of it, particularly when it comes to streaming content.
As for resets, via UI, pin-push, or the 30-30-30, I suppose I could do this but it's such a PITA to set everything back up. I have reservations for every known client, for one thing. I suppose I could save off an nvram show, exclude everything except all the stuff I really care about, then script a nvram set/commit after a factory reset. I would like to delay something like this, though, in favor of gathering more data about the behavior.
In closing, I have been a huge proponent of Asus for years. This is my 5th Asus device overall, and only the 2nd which I've had problems with. (2 were Asus tablets, one of which was stolen and its replacement eventually crapped out after years of travel and frequent ROM reflashes). But I'm a bit sour on Asus these days, and that began before I noticed this device randomly reboot. This device seems particularly buggy.
I guess I'm left with nothing but the 30-30-30, but ... eventually. In the meantime, I'll disable the nightly reboots but continue tracking uptime and load. If there is any other data I can regularly pull back, I'd love to hear it.
Thanks so much!