There are some really nice ideas in this subforum... Here are a couple features I find myself wishing we had and some thoughts on them:
Captive portal/Default home page for Wi-Fi Access Point:
Can it be added to AREDN? I understand there are OpenWRT packages that accomplish this. The use case would be that during a potential incident, it would be helpful if people that connected to the WiFi access point on the node were directed to a specific page. If you're connected to me, you can see the page I would use and see why it makes a good landing page during an incident response activity. http://km6slf-tcr1.local.mesh/
Enable/Disable All Tunnels:
Those of us with lots of tunnel connections have surely experienced the page reloading issue on the tunnel admin screens. A simple enable/disable all, possibly on the administration page, would save time and improve the UE
Store and load configurations:
As I gamed out incident response activities I realized that for some nodes, under certain circumstances, it may be necessary to make a slew of configuration changes in order to have them be as useful as possible. This is even more true for mobile and portable mesh nodes. I believe this can be done over SSH, but it would be nice if node configurations could be saved, exported, imported and loaded from the web GUI.
I would appreciate any feedback on these, including ideas for improvement and how to accomplish them in the meantime if it can be done over SSH. I'll put these on the GitHub if they aren't already there after getting some feedback here.
Captive portal/Default home page for Wi-Fi Access Point:
Can it be added to AREDN? I understand there are OpenWRT packages that accomplish this. The use case would be that during a potential incident, it would be helpful if people that connected to the WiFi access point on the node were directed to a specific page. If you're connected to me, you can see the page I would use and see why it makes a good landing page during an incident response activity. http://km6slf-tcr1.local.mesh/
Enable/Disable All Tunnels:
Those of us with lots of tunnel connections have surely experienced the page reloading issue on the tunnel admin screens. A simple enable/disable all, possibly on the administration page, would save time and improve the UE
Store and load configurations:
As I gamed out incident response activities I realized that for some nodes, under certain circumstances, it may be necessary to make a slew of configuration changes in order to have them be as useful as possible. This is even more true for mobile and portable mesh nodes. I believe this can be done over SSH, but it would be nice if node configurations could be saved, exported, imported and loaded from the web GUI.
I would appreciate any feedback on these, including ideas for improvement and how to accomplish them in the meantime if it can be done over SSH. I'll put these on the GitHub if they aren't already there after getting some feedback here.
"If you're connected to me"
For the rest of the world that is not connected to you, how about a screenshot?
(1) For your Wi-Fi Access Point, this feature is already available on some OTS APs and also in OpenWRT.
(2) Instead of redirecting a maintenance or configuration web page,
you could create a web page on your AREDN node and advertise it on your local network.
Folks would save a 'favorite' or 'default' web page on their browser:
http://km6slf-tcr1.local.mesh/incident.htm
You would provide any redirection if necessary.
images follow.
I hope this helps,
Chuck
I could do that, but it would be a smoother user experience if I could force the "home" page to be the url I provided. I don't want to risk having stressed people try to understand the mesh status screen during an incident without having me or someone knowledgeable about it on hand to guide them.
Here's a link to the home page that I stuck on a web-accessible remote hosted site for viewing.
https://demo.tri-citiesraces.org/
I said:
"(2) Instead of redirecting a maintenance or configuration web page,
you could create a web page on your AREDN node and advertise it on your local network.
Folks would save a 'favorite' or 'default' web page on their browser:
http://km6slf-tcr1.local.mesh/incident.htm ..."
You said:
"I could do that, but it would be a smoother user experience if I could force the "home" page to be the url I provided."
I am missing something because I thought
"http://km6slf-tcr1.local.mesh/incident.htm" is to be the URL you would provide.
No knowledge of people to 'try to understand the mesh status screen'.
You provide the URL, folks put that URL in their web browser, bingo-bango, done.
What am I missing?
73, Chuck
If your 'off-the-shelf' router does not already have a 'captive portal' feature,
connect the WAN port of your Wi-Fi router the the LAN port of a node on your local AREDN network.
Share the SSID and PASSPHRASE/PASSWORD with the folks at your 'site'.
I thought about creating a minimum stress environment for EmComm'ers, so
I created an 'Alias' "MoCo-incident" ('Montgomery County incident') on a node on the local AREDN network and
pointed that 'Alias' to the address of a web server on the local AREDN network.
On that web server I made the default page an HTML redirect to 'http://nc8q-services.local.mesh/MoCo-incident.htm'.
I created a local web page: 'MoCo-incident.htm'.
Here is the reduced stress part:
Now, on any computer, connected to the local AREDN network and
especially via your Wi-Fi Access Point,
one can enter
http://MoCo-incident
into the address box of their web browser and view the web page ('MoCo-incident.htm').
Season to taste.
73, Chuck
"if node configurations could be saved, exported, imported and loaded"
Yeah, kewel!
There is already a 'Download Support Data'.
Perhaps a 'configuration backup/restore' feature, either CLI or GUI or both, would suffice.
Chuck
Beat ya to that one. I put in a feature request for that (with more detail) on GitHub several months ago.
https://github.com/aredn/aredn/issues/160
I have 10 tunnels on the server side and three on the client side of one of my hAPs. It gets updated to almost every nightly, and I agree, it's a pain in the neck having to click the checkbox for each one with the required 10-15 second delay between each one.
I simply remove the VTUN module (and IperfSpeed modules on low memory devices) before upgrade. After upgrade, I install the IperfSpeed modules, then install VTUN after that reboot. All previous tunnel settings remain intact. No need to "disable" tunnel connections as that occurs automatically upon removal of the VTUN module!
I usually recommend rebooting the nodes after removal of the IperfSpeed and VTUN modules "before" upgrading. I can't imagine that the tunnels would still be working after the reboot.