Bug #4474
open
IP address change triggers reload of all packages
0%
Description
Hey!
When OpenVPN restarts and the clients or servers are assigned to interfaces, the packages are reloaded. They are even reloaded when the ip has not been changed at all...
Here the log showing two things. First, the real interface: ovpnc1 is known the the newwanip "process". Secound, the ip change of 10.40.91.2 -> 10.40.91.2 restarts packages.
Feb 25 21:27:28 php-fpm66452: /rc.newwanip: Creating rrd update script
Feb 25 21:27:29 php-fpm37734: /rc.linkup: Ignoring link event for ovpn interface
Feb 25 21:27:29 php-fpm37734: /rc.newwanip: rc.newwanip: Info: starting on ovpnc1.
Feb 25 21:27:29 php-fpm37734: /rc.newwanip: rc.newwanip: on (IP address: 10.0.8.xx) (interface: OVPNxxx1[opt2]) (real interface: ovpnc1).
Feb 25 21:27:29 check_reload_status: Reloading filter
Feb 25 21:27:30 php-fpm66452: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.40.91.2 -> 10.40.91.2 - Restarting packages.
Feb 25 21:27:30 check_reload_status: Starting packages
Files
Updated by Phillip Davis over 9 years ago
There are some packages that might like to know about interface state changes, including changes where the interface "goes away and comes back" in some way, even though the IP address... come back the same as previous. In the current system there is no standard interface to notify packages of changes, thus the brute-force package restart.
I seems to me it would be good to provide some better standard package notification method that can pass to packages some detail of the event and then each package can choose to ignore the event, restart completely or reload its config or do whatever it thinks appropriate.
Updated by Chris Buechler almost 9 years ago
- Subject changed from OpenVPN IP adress change triggers package reload to IP address change triggers reload of all packages
- Category set to Package System
- Status changed from New to Confirmed
- Affected Version set to All
as Phil noted it's not as simple as not doing this, as that breaks other situations that require it.
Updated by Daniel Grob almost 8 years ago
User "Kill Bill" wrote a patch that disables this behaviour for 2.2.2 and linked it in https://redmine.pfsense.org/issues/4868.
This is the same code, just ported to 2.3.2.
Updated by Kill Bill almost 8 years ago
Just FYI: That's not my patch, see the URL :)