Confused about `Merge Configuration`

42 views
Skip to first unread message

Ryan de Kock

unread,
Sep 26, 2024, 10:43:52 AM9/26/24
to OpenWISP
Hi.

First off - just getting started with openwisp & its pretty awesome!

The issue I'm having is as follows (with `Merge Configuration` enabled)

1. I create a template with some configuration variables
2. Using automatic registration, the device gets it config - all good
3. I adjust the configuration variables on the device settings, device gets updated config - all good
4. I modify the config `on device`, changes are applied - all good
5. I modify the original template json, devices locally applied changes are overridden - bad

So i thought that turning off `Merge Configuration` would resolve my issue, but this just seems to open another set of problems

The issue I'm having is as follows (with `Merge Configuration` disabled)

1. I create a template with some configuration variables
2. Using automatic registration, the device gets it config - all good
3. I adjust the configuration variables on the device settings, device gets updated config - all good
4. I modify the config `on device`, changes are applied - all good
5.  I modify the original template json, devices locally NOT applied BUT device goes offline as the Configuration Test seems to fail.


So I guess my question is, lets say I have a few hundred devices using a template to get an `initial` set of configuration properties (that the user can change at a later stage), every time I made an adjustment to that template, it will take all those devices offline for the period it takes for the test to fail - no way around this?

logread -f

Thu Sep 26 10:53:11 2024 daemon.info openwisp: Local configuration outdated

Thu Sep 26 10:53:11 2024 daemon.info openwisp: Downloading configuration from controller...

Thu Sep 26 10:53:11 2024 daemon.info openwisp: Configuration downloaded, now applying it...

Thu Sep 26 10:53:11 2024 daemon.info openwisp: Service network has been reloaded via procd/ubus

Thu Sep 26 10:53:11 2024 daemon.info openwisp: Service wireless has been reloaded via procd/ubus

Thu Sep 26 10:53:16 2024 daemon.info openwisp: Testing configuration...

Thu Sep 26 10:53:21 2024 daemon.warn openwisp: Configuration test failed (attempt 1)

Thu Sep 26 10:53:31 2024 daemon.warn openwisp: Configuration test failed (attempt 2)

Thu Sep 26 10:53:41 2024 daemon.warn openwisp: Configuration test failed (attempt 3)

Thu Sep 26 10:53:46 2024 daemon.err openwisp: Configuration test failed! Restoring previous backup

Thu Sep 26 10:53:46 2024 daemon.info openwisp: Service network has been reloaded via procd/ubus

Thu Sep 26 10:53:46 2024 daemon.info openwisp: Service wireless has been reloaded via procd/ubus



Federico Capoano

unread,
Sep 27, 2024, 3:22:36 PM9/27/24
to open...@googlegroups.com
Hi Ryan,

If the configuration test fails it may mean there's a problem with the configuration, in that case the configuration is rolled back.
This process takes time, the total time it takes depends on the amount of test_retries set, see the OpenWISP Config agent Settings documentation for more info.

In some cases, like if your devices are getting their internet uplink wirelessly, changing templates that affect the wireless stack can cause loss of connection for a few minutes and the test may fail because of this, generating a false positive situation: the config works, but the test fails because it's failing too early. In these cases you need to increase the amount of test_retries.

If the test is failing no matter what, the only solution is to test your changes on a test device before rolling it out to the entire network, which is pretty much standard practice in network automation. 

I hope I have understood your concerns well and provided some clarification.

Best regards
Federico Capoano


--
You received this message because you are subscribed to the Google Groups "OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwisp+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openwisp/1a99e751-70c8-4707-88ba-430b81f58b6an%40googlegroups.com.

Ryan de Kock

unread,
Oct 1, 2024, 9:58:52 AM10/1/24
to open...@googlegroups.com
Hi Federico,

Thanks for the reply!

Im glad that somewhere im hitting an error and this is not expected behaviour atleast, the problem is that, unless I've fundamentally misunderstood how all this is working - I can figure where the error would be coming from - is there anyway to debug it , maybe via openwisp_config?

1. I start with a basic WIFI Template

{
    "interfaces": [
        {
            "type": "wireless",
            "name": "wlan0",
            "mtu": 1500,
            "disabled": false,
            "network": "",
            "mac": "",
            "autostart": true,
            "addresses": [],
            "wireless": {
                "network": [
                    "{{LAN_NAME}}"
                ],
                "mode": "access_point",
                "radio": "radio0",
                "ack_distance": 0,
                "rts_threshold": 0,
                "frag_threshold": 0,
                "ssid": "{{SSID}} 2.4ghz",
                "encryption": {
                    "protocol": "wpa2_personal_mixed",
                    "key": "{{PSK}}",
                    "disabled": false,
                    "cipher": "ccmp",
                    "ieee80211w": "1"
                },
                "ieee80211r": true,
                "reassociation_deadline": 3000,
                "ft_over_ds": true,
                "maclist": []
            }
        },
        {
            "type": "wireless",
            "name": "wlan1",
            "mtu": 1500,
            "disabled": false,
            "network": "",
            "mac": "",
            "autostart": true,
            "addresses": [],
            "wireless": {
                "network": [
                    "{{LAN_NAME}}"
                ],
                "mode": "access_point",
                "radio": "radio1",
                "ack_distance": 0,
                "rts_threshold": 0,
                "frag_threshold": 0,
                "ssid": "{{SSID}} 5ghz",
                "encryption": {
                    "protocol": "wpa2_personal_mixed",
                    "key": "{{PSK}}",
                    "disabled": false,
                    "cipher": "ccmp",
                    "ieee80211w": "1"
                },
                "ieee80211r": true,
                "reassociation_deadline": 3000,
                "ft_over_ds": true,
                "maclist": [],
                "device": "radio1"
            }
        }
    ]
}


2. I go to the `Device` and I give it unique Variables for the SSID

3. I login to Openwrt and change the WIFI Password and save config

4. I modify the template and remove the `5ghz` suffix from the 5ghz radio

5. device becomes unreachable as the configuration test fails. (Note, this only happens if i untick `Merge Configuration`, if I enable it, the SSID is updated as expected)




--
Regards,
Ryan

Federico Capoano (nemesisdesign)

unread,
Oct 23, 2024, 10:59:36 AM10/23/24
to OpenWISP
It's really specific to your use case, if you untick merge configuration the configuration supplied from the server probably deletes some local configuration which you need, so you either need to replicate that in your templates or keep the default merging behavior enabled.

I hope this helps.

Federico

Reply all
Reply to author
Forward
0 new messages