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)
On Fri, Sep 27, 2024 at 9:22 PM Federico Capoano <[email protected]>
wrote:
> 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
> <https://openwisp.io/docs/dev/openwrt-config-agent/user/settings.html>
> 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
>
>
> On Thu, 26 Sept 2024 at 10:43, Ryan de Kock <[email protected]>
> wrote:
>
>> 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
>>
>>
>> --
>> 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 [email protected].
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/openwisp/1a99e751-70c8-4707-88ba-430b81f58b6an%40googlegroups.com
>> <https://groups.google.com/d/msgid/openwisp/1a99e751-70c8-4707-88ba-430b81f58b6an%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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 [email protected].
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/openwisp/CAAGgX6Jfv10%2B3W2vN5pJkUHbXDk2dnzWo6p7e1iXYiab5a%2B1XQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/openwisp/CAAGgX6Jfv10%2B3W2vN5pJkUHbXDk2dnzWo6p7e1iXYiab5a%2B1XQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
Regards,
Ryan
--
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 [email protected].
To view this discussion on the web, visit
https://groups.google.com/d/msgid/openwisp/CAD3bL_D3K-_g7iBLqjpGPfstxTJcmfPLOH-5km2N1mjB%2Bg5pwQ%40mail.gmail.com.
