Recently Nightly build features

8 posts / 0 new

Last post

Thu, 09/03/2020 - 13:45

w6bi

Recently Nightly build features

The latest AREDN nightly release has some nice changes:

Those confusing check boxes on the Advanced Configuration page have been changed to sliders to make their use a bit clearer.
AREDN has added Local Alerts capabilities. Nodes can now subscribe to a URL (defined in Advanced Configuration) to retrieve any local alert messages.

That results in something like this:

Configuring it and the alert server are explained very well at the bottom of this page: https://arednmesh.readthedocs.io/en/latest/arednGettingStarted/advanced_config.html. Local alerts can be configured for specific nodes, or all nodes watching a given alert server.

The Advanced Configuration warning banner has been made slightly wider to distinguish it from the Alerts banner. A WARNING has been added and the text color has been made pure white for contrast.
And maybe most importantly, you're now able to choose whether or not to have your nodes DHCP leased host names & IP addresses propagated over the rest of the mesh network or not. It defaults to allowing them propagate.

The host name/IP will still be resolvable from the localnode and will show up in the list of hosts on the localnode only. This allows for selected local AREDN network devices (e.g., switches, routers, cameras) to not be available over the rest of the mesh network.

In this example, I've stopped the addresses and host names of a local switch and wireless access point from propagating. Select the entries you want to stop from propagating, then save the settings.

As it's adopted and applied across the network this will shrink the size of the mesh status page, making it a bit easier to review. (Here in Southern California there are about 500 nodes and a thousand lines on the mesh status page).

More importantly, it will shrink the size of the OLSR routing table (and thus the size of the routing broadcast), easing the load on older, lower-performance nodes and potentially help stabilize large networks.

Comment from the author, KG6WXC:

"This will work immediately for new DHCP leases when the checkbox is selected. For existing DHCP leases, it may take a while for the network to update, if ever. To speed up the process of full network OLSR DNS updating, reboot all the nearest neighbor device(s) to the node you made these changes to. That seems to get the changes "out" to the rest of the network faster than normal."

I encourage everyone to consider updating to this nightly build and utilizing the Do Not Propagate feature as it makes sense for your QTH.

Sat, 09/05/2020 - 10:27

ko0ooo

alerts polling...

we've been experimenting with the local alerts feature...

polling every 12 hours seems a bit long... I could issue a local alert and it could be obsolete an hour later too long of an interval and updates would be missed manually updating is nice, assuming one remembers, and remembering when they last updated

how much overhead would be generated if polling were every 15 minutes? separate polling times for local and AREDN?

offering two local message repositories on the advanced setup page? redundancy never hurts

Richard ko0ooo

Sat, 09/05/2020 - 12:53

(Reply to #2) #3

AB7PA

Crontab entry for polling time

You can edit the crontab entry for aredn_message and set it to poll every 10 or 15 minutes, instead of once every 12 hours.

my-node # crontab -e
*/5 * * * * /usr/local/bin/fccid
* * * * * /usr/local/bin/rssi_monitor
* * * * * /usr/local/bin/snrlog
* * * * * /usr/local/bin/clean_zombie.sh
#0 */12 * * * /usr/local/bin/aredn_message.sh  (existing entry copied and modified below)
*/10 * * * * /usr/local/bin/aredn_message.sh

There are lots of things you could do with this alerts feature. One example is to have a program that grabs active National Weather Service severe weather alerts for your region and append them to the all.txt file for nodes on your local mesh (screenshot attached).

Sat, 09/05/2020 - 13:31

(Reply to #3) #4

ko0ooo

thanks...

thanks Stephen,

changed it to 10 minutes.. see how that plays

Richard ko0ooo

Sat, 09/05/2020 - 11:59

kc8ufv

Hmm... Just a thought on the

Hmm... Just a thought on the alert messages... Does the mesh support multicast? I'm thinking if it does, it could be a useful thing to have the alerts be pushed instead of pulled... That'd reduce bandwith requirements, and make it update theoretically immediately, good for short term alerts....

Tue, 09/08/2020 - 21:18

(Reply to #5) #6

AE6XE

multicast can be implemented

multicast can be implemented by deploying openwrt packages and custom AREDN firewall rules: https://openwrt.org/docs/guide-user/network/wan/udp_multicast . multicast provides most benefit when many people are subscribing to high bandwidth services (all at the same time). The subscribers to the content would not duplicate the data on a given network link, and only consume the links that are necessary to transmit the data.

sending small size and count of messages to many people using multicast, would have limited performance improvement. Setup of an ipCam viewed by many City EOCs at the same time over the mesh would significant reduce traffic.

Joe AE6XE

Tue, 09/08/2020 - 20:22

kg6wxc

nope

<strike>No multicasting on the mesh</strike>, some of us have tried it and it didn't work, which was not really a surprise. We still had to try though! :)

*edit* I sit corrected! Thanks for the info Joe! We might have to try it!

Fri, 09/11/2020 - 17:39

nc8q

full network OLSR DNS updating

"reboot all the nearest neighbor device(s) to the node you made these changes to."

Instead of rebooting 'nearest neighbors' or 'every other node on the network'.
Run this on the changed node:
/etc/init.d/olsrd stop; sleep 4m; reboot

I hope this helps, Chuck

Amateur Radio Emergency Data Network

Menu SF

You are here

Recently Nightly build features

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

Recently Nightly build features