delta/NetworkManager.git/src/NetworkManagerUtils.h, branch th/NMStringTable

core: move NMDevice's ip6_property_path() to NetworkManagerUtils

2014-03-04T22:04:01+00:00

core: match IPv4 'disabled' method to 'auto' when device has no link

2014-03-04T21:21:58+00:00

If IPv4 configuration did not succeed or the device has no IPv4 addresses
when NM restarts, it will detect the existing device configuration as
'disabled'.  This can happen when a bridge has no slaves and thus cannot
perform IPv4 addressing because it has no carrier (since bridge carrier
status depends on slave carriers).  When NM starts or restarts, it
sees the bridge has no IPv4 address and assumes the IPv4 method is
'disabled'.  This creates a new connection, which blocks any slave
connections from activating if they specify their master via UUID
 (since the bridge's active connection is generated).

Fix this by allowing matches from 'disabled' to 'auto' if the device
has no carrier, and there are no other differences between the
original and the candidate connections.

core: add function nm_utils_ip6_address_clear_host_address()

2014-02-14T20:40:58+00:00

Signed-off-by: Thomas Haller

core: add nm_utils_get_monotonic_timestamp_us() function

2014-02-14T14:53:11+00:00

Signed-off-by: Thomas Haller

core: add nm_utils_get_monotonic_timestamp_* functions

2014-01-30T18:51:45+00:00

https://bugzilla.gnome.org/show_bug.cgi?id=720833

Signed-off-by: Thomas Haller

core: add nm_utils_ascii_str_to_int64() function

2014-01-22T11:12:02+00:00

Signed-off-by: Thomas Haller

core: fuzzier matching of generated connections to persistent ones

2013-12-05T23:09:46+00:00

When generating a connection, if the device has no non-link-local IPv6
address, then it's unclear whether (a) the connection was link-local
originally, or (b) the connection was 'auto' but IPv6 failed or timed
out.

In this case, if there is a persistent connection that is 'auto' but
the generated connection is 'link-local', the persistent connection
should be used.

Add a more-testable framework for doing the connection matching to
handle this.

core: capture DNS configuration from resolv.conf when generating connections

2013-11-22T21:01:10+00:00

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.

core: remove redundant sysctl utilities

2013-11-15T15:49:43+00:00

NMDevice was still using the old sysctl functions from
NetworkManagerUtils rather than the new NMPlatform ones. Fix it, and
remove the old functions.

core: don't have IP4 and IP6 configs on slaves

2013-10-14T16:07:37+00:00

Although it's convenient in some places to have IP configs on all
connections, it makes more sense in other places to not have IP
configs on slaves. (eg, it's confusing for nmcli, etc, to report a
full NMSettingIP4Config on a slave device). So revert parts of the
earlier patch. However, it's still safe to assume that s_ip4 != NULL
if method != DISABLED, so some of the earlier simplifications can
stay.

Also, add nm_utils_get_ip_config_method(), which returns the correct
IP config method for a connection, whether the connection has IP4 and
IP6 settings objects or not, and use that to keep some more of the
simplifications from the earlier patch.