Management: add reload-push-options & Fix PUSH_UPDATE logic
#916
Conversation
|
Thanks for working on this, and thanks for sending all the good stuff to the At this point in time, close to the 2.7 release, the big feature enhancement might be a bit too much for us to digest. The bugfix patch really should go in before 2.7.0 - @mrbff can you review? |
|
Yes, I will review asap |
|
It looks bigger than it is; most of it is just end-to-end tests. The code change itself is not that much.... Please have a closer look at the gc_arena stuff; I hope I got that right. I'm basically creating a new options.push_list and then switching the current with the new one. |
|
regarding the management command:
is the wording "sync" ok or should i change it to "broadcast" because there's "push-update-broad"? |
|
|
|
Changed the naming, adjusted everything mentioned in the comments. Anything else? Any chance for 2.7.0? |
|
The end result should be "one bugfix commit" (squashing all parts that are "bugfix" related), and "one feature commit" (new feature, with the 'sync' rename). Bugfix can - and should - go into 2.7.0, "new feature" needs more review and (likely) more discussion. |
|
ok @cron2, i'm opening a new PR here for bugfix only and send the diff to the mailing list |
|
@maurice2k please do not open a new pr. You can update/force push to this PR to update it. |
This adds a new management command 'reload-push-options' that allows reloading the push options from the configuration file without restarting the server. This is useful for updating routes or DNS settings for new clients without dropping existing connections. The command supports an optional 'update-clients' argument. When provided, the server will also synchronize the new options to currently connected clients by: 1. Calculating the difference between old and new push options. 2. Sending '-instruction' (e.g. -route) to remove old options. 3. Sending new options via PUSH_UPDATE. This includes a comprehensive integration test suite in tests/reload_push_options.
Previously, the logic for resetting push options (like 'route') was based on `update_options_found` which was local to `apply_push_options`. This meant that if a PUSH_UPDATE was split across multiple continuation messages, the state was lost, causing routes to be reset multiple times (once per message chunk) rather than once per update sequence. This patch moves the state tracking to `struct options` as `push_update_options_found`, allowing it to persist across the entire PUSH_UPDATE sequence. This fixes an issue where large route lists sent via PUSH_UPDATE would result in only the last chunk's routes being applied, or previous routes being continuously deleted and re-added. Added unit tests to verify the fix.
maurice2k
force-pushed
the
feature/reload-push-options
branch
from
7a83c25 to
2dd10d6
Compare
|
adjusted it here, merged the two patches (feature + bugfix) back into two commits. should i remove the bugfix commit from this PR? or remove the other PR? |
|
Final patches have to be submitted to the mailing list. Once they are there, PRs on GitHub are not that useful anymore (they are good for a preliminary review, but nothing else) and can be closed. So it doesn't matter how PRs are structured here, as long as they get the needed attention and patches are then submitted to the openvpn-devel mailing list. |
6 participants
Overview
This PR introduces a new management command
reload-push-optionsto allow dynamic updating of client configurations (routes, DNS, etc.) without restarting the server or disconnecting clients. It also includes a critical fix forPUSH_UPDATEhandling when messages are split across multiple chunks (continuation messages).1. Feature:
reload-push-optionsAdministrators can now trigger a reload of push options from the server configuration file via the management interface.
Usage
pushoptions from the config file. New clients connecting after this will receive the new options. Existing clients are unaffected.update-clients: Reloads options AND synchronizes them to currently connected clients.Update Logic
When
update-clientsis used, the server:-route) for option types that have changed or been removed.PUSH_UPDATE.This allows for seamless updates of routing tables and network settings on live VPNs.
2. Bug Fix:
PUSH_UPDATEContinuation LogicThe Issue
Previously, the state tracking for which option types had been "reset" (e.g.,
OPT_P_U_ROUTE) was stored in a local variableupdate_options_foundwithinapply_push_options().If a
PUSH_UPDATEmessage was large enough to be split into multiple fragments (usingpush-continuation), this state was lost between fragments.The Fix
The state variable has been moved to
struct optionsaspush_update_options_found. This ensures the "reset state" persists across the entirePUSH_UPDATEsequence and is only cleared once the full sequence is processed.Testing
Integration Tests
Added a Docker-based integration test suite in
tests/reload_push_options/.tests/reload_push_options/run.shUnit Tests
test_incoming_push_continuation_route_accumulationtotest_push_update_msg.cto verify that route lists accumulate correctly across multiple message chunks.