ampr-ripd: changes to support future config via luci

[K2IE]

In developing a Luci interface for this package, it was determined
that there is utility in parsing out the address and netmask parts
of tunnet into separate values and adding the host address to
the config file.

📦 Package Details

Maintainer: @K2IE

Description:
Change /etc/config/ampr-ripd to no longer use tunnet, instead
using amprnet and amprmask for CLI configuration
Add amprhost to the config for future use in by luci
Modify initscript to migrate to the new options when needed

🧪 Run Testing Details

• OpenWrt Version: 24.10.2
• OpenWrt Target/Subtarget: bcm27xx/bcm2711
• OpenWrt Device: RPi CM4

Tested as a new install and as upgrade to rev 2. Worked as expected in all cases.

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[GeorgeSapkin]

The commit subject should be on the first line instead of the author.

[K2IE]

The commit subject should be on the first line instead of the author.

This was fixed.

[GeorgeSapkin]

I'm getting a:

ampr-ripd-2.4.2-r3.post-upgrade: sh: out of range

when upgrading from r2 to r3 with an existing config. The config migration seems to work though.

And I'm getting:

root@OpenWrt:/# service ampr-ripd start
sh: out of range
root@OpenWrt:/# /etc/init.d/ampr-ripd start
sh: out of range
root@OpenWrt:/tmp# /etc/init.d/ampr-ripd restart
sh: out of range

when trying to (re)start the service even after running configure again.

This is happening on the latest snapshot from Oct 4 with no other packages.

[K2IE]

I am unable to replicate. Please repeat but before you try a restart of ampr-ripd, grab a copy of /etc/config/ampr-ripd and post it here so that I can test with your exact config.

[K2IE]

@GeorgeSapkin I am unable to reproduce what you're reporting. I installed the latest 24.10 snapshot, I installed the current ampr-ripd package, then I installed the package that represents this pull request. No errors, no issue. This was done with an x86 build.

Either please try again or post me a copy of your /etc/config/ampr-ripd as it exists before you install the r3 package over the existing r2, along with the exact steps you followed so that I an try to replicate.

[GeorgeSapkin]

I retested this again with a clean SDK and SNAPSHOT (not 24.10 SNAPSHOT) from Oct 20 with no other packages built/installed.

Clean install (this PR) works as expected since the new default config is used.

Upgrade from r2 to r3 with the sample (i.e. the default) config from r2 works as expected as well since the old config is deleted and the new default is installed.

---

Config after r2 install and running configure with a custom mask:

Note

255.255.255.0 changed to 255.255.0.0 so the config is different from the default and is not deleted on upgrade.

/etc/init.d/ampr-ripd configure 44.127.254.1 255.255.0.0 44.127.254.0

config ampr-ripd 'network'
	option tunnet 44.127.254.0/255.255.0.0

Upgrade r2 to r3 with an existing config:

ampr-ripd-2.4.2-r3.post-upgrade: sh: out of range

Config after upgrade:

config ampr-ripd 'network'
	option amprnet '44.127.254.0'
	option amprmask '255.255.0.0'

At this point the service is not running.

Trying to start the service manually.

root@OpenWrt:/tmp# /etc/init.d/ampr-ripd start
sh: out of range

The rest is the same as above. Reconfiguring doesn't help. This is what the config looks like after that:

config ampr-ripd 'network'
	option amprnet '44.127.254.0'
	option amprmask '255.255.0.0'
	option amprhost '44.127.254.1'

Notice in both cases the enabled option is missing. So at the very least both the upgrade and configure scripts should set the enabled option and handle the situation when it's not set properly (i.e. set the default).

Additionally upgrade currently doesn't set amprhost. What is the expected outcome here?

---

For future PRs I think it makes sense to runtest things on a SNAPSHOT and not stable-SNAPSHOT (e.g. 24.10 SNAPSHOT in your case), considering that SNAPSHOT has quite some differences since the last stable. For example the packaging system. Your changes will go through main branches after all and that's where they should work.

[K2IE]

@GeorgeSapkin I want to replicate what you're doing, but I am not clear about where to obtain the appropriate snapshot. What I'm seeing for the main branch is now all apk and we're still working with an ipk here. Please provide a pointer to the image or source you're using.

[GeorgeSapkin]

The latest snapshots are here: https://downloads.openwrt.org/snapshots/targets/

I don't think that's relevant to the issue with the missing options on upgrade though.

[K2IE]

The latest snapshots are here: https://downloads.openwrt.org/snapshots/targets/

I don't think that's relevant to the issue with the missing options on upgrade though.

We are now in apk land which is new to me. Much to learn I suppose.

@GeorgeSapkin When installing the apk for r3, I see that the add is running a post-upgrade script. That is what is causing the sh: out of range issue. What/where is the post-upgrade script?

[GeorgeSapkin]

Have a look at https://github.com/openwrt/openwrt/blob/main/include/package-pack.mk

[K2IE]

Latest push tested on x86 master snapshot and corrects reported issues. @GeorgeSapkin please advise of your findings.

[GeorgeSapkin]

Instructions at the end of configure imply that simply restarting the service should be enough. However if enabled is not set or is 0, that will do nothing. Maybe configure should set enabled to 1 as well?

Other than the comments below, the upgrade from r2 to r3 seems to be working as expected now.

[K2IE]

Instructions at the end of configure imply that simply restarting the service should be enough. However if enabled is not set or is 0, that will do nothing. Maybe configure should set enabled to 1 as well?

Default set and error msg added.

[GeorgeSapkin]

It's kind of confusing that I'm getting a configuration warning even when a full r3 config exists on install (not upgrade):

ampr-ripd-2.4.2-r3.post-install: ampr-ripd is not fully configured.
ampr-ripd-2.4.2-r3.post-install: You must run '/etc/init.d/ampr-ripd configure'.

config ampr-ripd 'network'
	option amprnet '44.127.254.0'
	option amprmask '255.255.123.0'
	option amprhost '44.127.254.254'
	option enabled '1'

Is something preventing the package from reconfiguring itself at this point instead if using the default values? That's the idea behind preserving a config between installs.

[GeorgeSapkin]

Suggested change

	config_get enabled network enabled 0
	config_get_bool enabled network enabled 0

[K2IE]

It's kind of confusing that I'm getting a configuration warning even when a full r3 config exists on install (not upgrade):

ampr-ripd-2.4.2-r3.post-install: ampr-ripd is not fully configured.
ampr-ripd-2.4.2-r3.post-install: You must run '/etc/init.d/ampr-ripd configure'.

config ampr-ripd 'network'
	option amprnet '44.127.254.0'
	option amprmask '255.255.123.0'
	option amprhost '44.127.254.254'
	option enabled '1'

Is something preventing the package from reconfiguring itself at this point instead if using the default values? That's the idea behind preserving a config between installs.

option amprhost '44.127.254.254' is the default IP address. This shows that we are not configured properly, so by design we do not run. This is as intended. If you were a licensed radio amateur you would have obtained an authorized subnert via the ARDC portal and used /etc/init.d/configure ...

[GeorgeSapkin]

option amprhost '44.127.254.254' is the default IP address. This shows that we are not configured properly, so by design we do not run. This is as intended. If you were a licensed radio amateur you would have obtained an authorized subnert via the ARDC portal and used /etc/init.d/configure ...

The point is not about the values in that exact config or that exact IP, but about the lack of re-configuration logic on reinstall. Is there anything like that when the values are valid? I can't seem to find it. Which, again, defeats the purpose of saving the modified config between installs.

[K2IE]

option amprhost '44.127.254.254' is the default IP address. This shows that we are not configured properly, so by design we do not run. This is as intended. If you were a licensed radio amateur you would have obtained an authorized subnert via the ARDC portal and used /etc/init.d/configure ...

The point is not about the values in that exact config or that exact IP, but about the lack of re-configuration logic on reinstall. Is there anything like that when the values are valid? I can't seem to find it. Which, again, defeats the purpose of saving the modified config between installs.

I just tested the following on a system without ampr-ripd:

apk update
apk install ampr-ripd
/etc/init.d/ampr-ripd configure 44.54.12.33 255.255.255.240 44.54.12.32 (example IPs that are not the documentation defaults)

Results as expected.

apk add --allow-untrusted ampr-ripd-2.4.2-r3.apk

Results as expected, config preserved.

[GeorgeSapkin]

Results as expected, config preserved.

I was talking about the network config and its reconfiguration. And the scenario where a package is installed with no other version being installed at that moment, but there is an existing non-default config and not simply upgrading r2 to r3, e.g.:

1. install r3
   • network interfaces have default values
2. configure with non-default values
   • package config is modified
   • network interfaces have updated values
3. remove r3
   • modified package config should still exist
   • network configuration is removed
4. reinstall r3
   • network interfaces have default values even though a non-default package config exists
   • service cannot start

Just to be sure I tried this again with the latest changes:

# delete existing version
root@OpenWrt:/tmp# apk del ampr-ripd
(1/5) Purging ampr-ripd (2.4.2-r3)
ampr-ripd-2.4.2-r3.pre-deinstall: Executing script...
ampr-ripd-2.4.2-r3.pre-deinstall: Terminated
ampr-ripd-2.4.2-r3.post-deinstall: Executing script...
ampr-ripd-2.4.2-r3.post-deinstall: Removing firewall rules...
ampr-ripd-2.4.2-r3.post-deinstall: Removing network rules...
ampr-ripd-2.4.2-r3.post-deinstall: Removing firewall zone forwarding rules...
ampr-ripd-2.4.2-r3.post-deinstall: Removing firewall zones...
ampr-ripd-2.4.2-r3.post-deinstall: Removing network interfaces...
(2/5) Purging kmod-ipip (6.12.51-r1)
kmod-ipip-6.12.51-r1.pre-deinstall: Executing script...
(3/5) Purging kmod-iptunnel (6.12.51-r1)
kmod-iptunnel-6.12.51-r1.pre-deinstall: Executing script...
(4/5) Purging kmod-iptunnel4 (6.12.51-r1)
kmod-iptunnel4-6.12.51-r1.pre-deinstall: Executing script...
(5/5) Purging ip-tiny (6.14.0-r1)
ip-tiny-6.14.0-r1.pre-deinstall: Executing script...
ip-tiny-6.14.0-r1.pre-deinstall: add alternative: /sbin/ip -> /bin/busybox
OK: 20 MiB in 149 packages

# existing non-default config is preserved
root@OpenWrt:/tmp# cat /etc/config/ampr-ripd 

config ampr-ripd 'network'
	option amprnet '44.127.254.0'
	option amprmask '255.255.0.0'
	option amprhost '44.127.123.1'
	option enabled '1'

# network interfaces are removed
root@OpenWrt:/tmp# uci show network.amprlan.ipaddr
uci: Entry not found
root@OpenWrt:/tmp# uci show network.amprwan.ipaddr
uci: Entry not found

# reinstall app
root@OpenWrt:/tmp# apk add --allow-untrusted ./ampr-ripd-2.4.2-r3.apk 
(1/5) Installing ip-tiny (6.14.0-r1)
ip-tiny-6.14.0-r1.post-install: Executing script...
ip-tiny-6.14.0-r1.post-install: add alternative: /sbin/ip -> /usr/libexec/ip-tiny
(2/5) Installing kmod-iptunnel (6.12.51-r1)
kmod-iptunnel-6.12.51-r1.post-install: Executing script...
(3/5) Installing kmod-iptunnel4 (6.12.51-r1)
kmod-iptunnel4-6.12.51-r1.post-install: Executing script...
(4/5) Installing kmod-ipip (6.12.51-r1)
kmod-ipip-6.12.51-r1.post-install: Executing script...
(5/5) Installing ampr-ripd (2.4.2-r3)
ampr-ripd-2.4.2-r3: installing file to etc/config/ampr-ripd.apk-new
ampr-ripd-2.4.2-r3.post-install: Executing script...
ampr-ripd-2.4.2-r3.post-install: Installing default routing rules...
ampr-ripd-2.4.2-r3.post-install: Installing default network interfaces...
ampr-ripd-2.4.2-r3.post-install: Installing default firewall zones...
ampr-ripd-2.4.2-r3.post-install: Installing default firewall rules...
ampr-ripd-2.4.2-r3.post-install: ampr-ripd is not fully configured.
ampr-ripd-2.4.2-r3.post-install: You must run '/etc/inid.d/ampr-ripd configure'.
OK: 21 MiB in 154 packages

# config is still the same
root@OpenWrt:/tmp# cat /etc/config/ampr-ripd 

config ampr-ripd 'network'
	option amprnet '44.127.254.0'
	option amprmask '255.255.0.0'
	option amprhost '44.127.123.1'
	option enabled '1'

# network interfaces have default values despite the non-default config existing
root@OpenWrt:/tmp# uci show network.amprlan.ipaddr
network.amprlan.ipaddr='44.127.254.254'
root@OpenWrt:/tmp# uci show network.amprwan.ipaddr
network.amprwan.ipaddr='44.127.254.254'

What is the expected outcome here? What do you want the user to do? As it stands now, the service is not starting, even though a config exists, because there's not reconfiguration logic for network and default values are written on reinstall instead.

We had this discussion multiple times now, including in the initial PR.

Important

If the config exists on install, and there is enough information for the package to function, the package should function without any additional intervention, like running configure to fill in the same information that already exists in the config again.

To sum it up, use the same configuration logic that is now in configure in the uci-defaults scripts when an existing config is found and valid.

[K2IE]

What is the expected outcome here? What do you want the user to do? As it stands now, the service is not starting, even though a config exists, because there's not reconfiguration logic for network and default values are written on reinstall instead.

We had this discussion multiple times now, including in the initial PR.

Oh, THIS again?

The expected outcome going back to the initial PR was that an uninstall would remove any trace of ampr-ripd from the system, including configurations. I provided a very sound reason for this, but YOU insisted that we not remove /etc/config/ampr-ripd. So I relented, knowing fully that leaving it in place would be completely useless. I also reserved the right to revisit this matter, and I suppose we are doing so now.

Let us now revisit the sound reason that this package does things a bit differently from the way other packages have handled configurations. A primary consideration here is that ARDC, as custodian of the 44.x address space, by policy limits use to licensed radio amateurs for non-commercial use.

PR #26259 included an rm of /etc/config/ampr-ripd which you essentially filibustered on until I removed it. My contemporaneous comments from said PR were that:

"ARDC (the custodian of Net 44) is concerned about any misconfigurations that could potentially disrupt Net 44. That is the logic behind the deletion of the /etc/config/ampr-ripd file, which defines the tunnet parameter that is passed to ampr-ripd. If someone were to reinstall ampr-ripd, we'd want them to thoughfully have to go through the initscript configure step again to make sure that the assigned network number is properly configured. Since you object to the deletion, the next best move is to reset to the default documentation network, which cannot cause any harm.

"As you've pointed out, this is a very special use case, and as member of the ARDC Technical Advisory Committee, I am attempting to ensure appropriate and non-detrimental use. Consider the deletion (or reset to default) as insurance. There is no legitimate purpose in our use case to save the prior config, which I believe to be your rationale."

44 Net is for experimentation. Experiments can go wrong. A good cleanup method is needed.

There was never any consideration of auto reconfiguration on reinstall. That is a new feature request that you are making. I suggest that it has no place in this PR for an existing package. You could open an issue for discussion. Should you do so, I will solicit feedback from the actual users of this package, licensed radio amateurs with 44 Net allocations to get their feedback on whether an uninstall should completely cleanup.

To summarize, I have presented valid reasons for the cleanup. You've presented the "we've always done it this way" alternative. Find me some current 44 Net participants using this package who agree that automatic reconfiguration on reinstall is a desirable feature rather than an obstacle and it will certainly get my attention.

But IMHO, THIS PR IS NOT THE PLACE TO RESOLVE THIS MATTER. What is up for approval is a cleaner approach to the configuration which lends itself to use by the luci configuration interface under development.

[KC2PVM]

To summarize, I have presented valid reasons for the cleanup. You've presented the "we've always done it this way" alternative. Find me some current 44 Net participants using this package who agree that automatic reconfiguration on reinstall is a desirable feature rather than an obstacle and it will certainly get my attention.

I have been a licensed amateur radio operator since 2006, and I have managed large software development efforts for 20+ years. The proposal put forth by @K2IE to completely remove the configuration in an uninstall is the best option to ensure that a misconfiguration does not impact the overall network. I support my position with the realization that Net44 is an experimental network, and any uninstall should neatly clean up all configurations. I see no practical use case where an amateur radio operator would uninstall, and then reinstall the package using the same configuration. I can't imagine any situation where that would occur, or be desirable.

[kb2ear]

I support an uninstall of the ampr-ripd completely cleaning up any configurations. I am a licensed radio amateur with Net 44 allocations, and use them daily. Leaving the configs could pollute the network after reinstall.

[GeorgeSapkin]

I've already shared my thoughts about the way configuration is handled in this package and that I don't approve it. Since I don't want to die on this hill and the discussion is becoming increasingly heated, I'd rather let somebody else handle this.