Creating a requested feature list

I would like to see the startup_macro_delay option added to ASL3. It was available in earlier versions. e.g. startup_macro_delay=45 to delay the execution by 45 seconds.

It would also be nice if an event would occur any time the host IP address changes, that could then trigger a macro in the rpt.conf [events] section. Sometimes IP addresses are not obtained until after ASL has started, or can change at other times eg. if the router restarts. In these cases it can be important for users to have a reliable function to announce the new IP address.

This was never in ASL. It may have been something in HamVOIP. But we can’t code-share with them about it.

Since app_rpt doesn’t track IP addresses of its host, there’s no feasible way to create an event for it. This is best done with a cron script or systemd service/timer to “notice” and alert about it.

Ah OK. I may have seen and used this feature in the HamVOIP distrib. I have been looking through the code for ASL3 on GitHub (/apps/app_rpt.c#) but I do not understand how to modify and promote any changes to a dev environment. Is there a guide?

Honestly, I don’t get the need to “announce” a nodes IP address. We’ve moved past the days where you have a headless device and had no way to determine its local IP address. If you need to connect to a node by its address then why not use the available DNS service discovery (e.g. ssh node1234.local)?

An example is when traveling and you connect to a public network you have no control over. The node will get a DHCP address but you have no easy way to know what that is. Users want to just type in the node’s IP into their smartphone dashboard app, and not need to take any extra steps, or wait around for a DDNS service to update. If you can suggest how to set up a simple, free and reliable DDNS service on Deb12 that would be great. I have tried some DDNS services in the past but had reliability issues, delays, etc. Whereas if the node announces its IP on boot that’s pretty simple and foolproof.

Or maybe the ASL registration server can provide a DDNS function once the node registers? Or is that HV only? If it is HV only, I hereby request that the ASL registration server be able to provide this function. Thanks

To find the local node IP you want to use DNS Service Discovery. On many linux systems, including our Raspberry Pi Appliance, this is provided by the Avahi daemon. If you are starting from scratch with Debian you can use apt install avahi-daemon. When installed/enabled you can just ssh node1234.local or browse http://node1234.local without needing to know the IP.

If you need the public IP then, yes, some form of DDNS would be needed. Fortunately, the ASL registration system ensures that DNS information for each node is available. A simple query for <node#>.nodes.allstarlink.org (or <node#>.remotebase.nodes.allstarlink.org for “remote” nodes) will get you the public/registered IP.

2 Likes

Firstly, thanks for fixing the lnkacttimerwarn functionality. (Bug 515, 517). I have just installed the latest beta and can confirm that this is working again.

The Link Activity Timer functionality doesn’t provide the the feature set I would like to see. The timer starts when there has been a change to the connection state. This could be establishing a new connection or a performing a disconnection. If we set the lnkacttime to 180 (3 mins) the timer starts counting up after the change to the connection state. If there has been no local RF activity, the timer will reach 180 and any selected macro defined by lnkactmacro will run. If there is local RF activity at say 120 seconds, the timer is reset to 0 and starts counting up again.

I would like to have a separate new feature created that is very similar to the existing Activity timer but instead of waiting for a local RF signal to reset the timer, any (internet) activity on the link causes the timer to be reset to 0. This would be useful to identity any periods of inactivity and then ‘do something’ by running a macro. So for example, if there has been no activity on the current connection, the macro could then perform a disconnect/reconnect to a busier/default connection. Or a gateway keeper might decide to leave the node in a disconnected state if there has been no activity for a given period on the current connection.

Since you know the what you’re looking for it would best to create a GitHub issue / enhancement request with details of the desired functionality.

Where to start : ASL3 Support

and, knowing where we would need to make changes, your enhancement request would be best filed with the GitHub: app_rpt repo.

Done.

I created a GitHub issue. #553

I guess that this will picked up and then get assigned as ‘an enhancement’. I couldn’t do this myself.