There can be multiple default routes for an interface with different
metrics. Grab the gateway of the default route with the lowest
metric as the overall gateway of the IP config. Otherwise the rest
could get left in the config and applied at random times.
If the interface who's IP configuration is being captured has the default
route, then read DNS servers from resolv.conf into the NMIP[4|6]Config.
This allows NetworkManager to repopulate resolv.conf if anything changes.
For example, if the system does not define a persistent hostname, then
when a device which has generated a connection activates, a hostname
lookup will be performed. The results of that lookup may change resolv.conf,
and thus NetworkManager must rewrite resolv.conf. Without capturing
DNS information at startup when generating connections, an empty
resolv.conf would be written.
Follow the IP configuration the device currently has. For IPv6, this means
not using LINK_LOCAL if the interface doesn't have a LINK_LOCAL address.
Otherwise, NM assumes too much and may begin to activate an interface that
has no IP configuration, then time out and deactivate that device.
Also improve nm_ip4_config_dump to print all properties and make
use of nm_platform_*_to_string.
Also, ensure that never_default is set to gboolean 1 or 0.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
This new function copies the entire configuration of an existing
NMIP[46]Config object (src) and replaces the configuration in the destination
object (dst) in-place.
Signed-off-by: Thomas Haller <thaller@redhat.com>
libgsystem contains more than just the local allocation macros; in the
future we will likely want to make use of some of this such as the
structured logging support.
Before, when a route failed to be added, NM stopped adding further
routes. However, the activation still continued and the user was not
notified about the error.
Adding a route might fail for example if the gateway is not on one of
the subnets of the interface.
Now, a failure to add a route makes the activaion fail. If the
connection has autoconnect=yes, this might result in some unsuccessful
reconnection attempts.
In the future, we might want to distinguish between manually added routes
and routes from RA/DHCP. So that connecting to a wrongly configured DHCP
server still works for most parts.
https://bugzilla.redhat.com/show_bug.cgi?id=999544
Signed-off-by: Thomas Haller <thaller@redhat.com>
The fix in commit b5b43a6d65 missed the
release of the route instance (because nm_setting_ip4_config_add_route
does not take over the passed route but duplicates it).
So the orginal error was to free the route with the wrong deallocation
method gs_unref_object instead of nm_ip4_route_unref.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Most places except the tests don't want the default route when asking
the platform for all routes, so make that simpler by just adding a
parameter for including the default route or not.
Like IPv6, keep the DHCP/LLv4 config separate and combine it with the
NMSettingIP4Config to arrive at the final, combined IP4 config. This
brings the behavior in line with IPv6 code flow and will allow adding
the VPN routes config into the mix more easily.
Callers of these functions now only care whether two IP configs are
different and not what specific property changed, so we can simplify
this code down to a simple comparison for equality, based on the hashing
that's already done for the DNS manager.
Note that this patch doesn't effectively change any code.
Functions moved from nm-system:
* nm_system_apply_ip?_config → nm_ip?_config_commit
* ip?_dest_in_same_subnet → nm_ip?_config_destination_is_direct
Functions moved from NetworkManagerUtils:
* nm_utils_merge_ip?_config → nm_ip?_config_merge_setting
Functions renamed (and moved down to form one group):
* nm_ip?_config_new_for_interface → nm_ip?_config_capture
(The rationale for the rename is that from the achitectural point of
view it doesn't matter whether the function creates a new object or
updates an existing one. After the rename, it's obvious that
nm_ip?_config_capture() and nm_ip?_config_commit() are counterparts of
each other.)
Using the new gateway-ping-timeout property, send pings to the first
gateway address until it replies or the timeout is reached, to deal
with dumb hardware that indicates carrier on but doesn't actually
pass traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=702515
NM handles the default routes, so they shouldn't show up in the NMIP4Config
for any interface. They get exposed via the 'default' and 'default6' properties
of the ActiveConnection instead.
When providing a service on the bus daemon and a private connection,
we'll need to track objects so we can register them with the
private connection too. Thus all registration/unregistration
calls have to go through the NMDBusManager, not straight to
dbus-glib.
The various nm_ip[46]_config_add_* routines were inconsistent in their
behavior when trying to add a duplicate item: add_address() and
add_route() would add it anyway; add_nameserver() and add_wins() would
g_return_if_fail(); and add_domain() and add_search() would return
silently. Update to use the "return silently" behavior everywhere.
In particular: if we get an RDNSS message listing the same nameserver
twice, don't cause a warning. (rh #820752)
Fix a few issues here:
- nm_utils_merge_ip4_config() didn't reset domains, which would cause domains
to still be used even if the user elected to ignore DHCP-provided DNS
- nm_ip4_config_add_domain() and nm_ip4_config_add_search() didn't filter
duplicates
- nm_ip4_config_reset_searches() leaked everything
- If the user had specified an appended search in the connection, that search
would be added to the 'searches' field in resolv.conf, but any server
returned domains in 'domain_name' would be ignored because at least one
search existed.
Fixes a crash with PropertyChanged signals (triggered when using wifi + vpn and
rmmod-ing the driver) where properties_changed_info_destroy() wouldn't get
called on object destruction becuase the GObject finalize method never got
called for the DHCP4Config and IP4Config objects.
Don't do anything with WINS servers (dispatcher scripts installed with
samba could certainly update samba's idea of WINS servers), but at least
provide them so that the VPNs that can get upstream WINS servers can
at least make other stuff aware of them.
* libnm-util/libnm-util.ver
libnm-util/nm-setting-ip4-config.c
libnm-util/nm-setting-ip4-config.h
- Add 'never-default' property, which when true indicates that a
connection should never be the default connection
* src/nm-ip4-config.c
src/nm-ip4-config.h
- (nm_ip4_config_get_never_default, nm_ip4_config_set_never_default):
Add never-default helpers
* src/NetworkManagerUtils.c
- (nm_utils_merge_ip4_config): update never-default when merging the
IP4 setting to the IP4 config
* src/NetworkManagerSystem.c
- (nm_system_apply_ip4_config): if the connection is never-default,
don't add routes without a gateway
* src/NetworkManagerPolicy.c
- (get_best_device): don't let never-default connections be the best
- (update_routing_and_dns): handle never-default for VPN connections
* system-settings/plugins/ifcfg-rh/reader.c
- (make_ip4_setting): handle never-default by checking GATEWAYDEV
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/branches/NETWORKMANAGER_0_7@4378 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
