Commit Graph

57 Commits

Author SHA1 Message Date
Thomas Haller
3793804314 libnm: rework setting metadata for property handling
NMSetting internally already tracked a list of all proper GObject properties
and D-Bus-only properties.

Rework the tracking of the list, so that:

- instead of attaching the data to the GType of the setting via
  g_type_set_qdata(), it is tracked in a static array indexed by
  NMMetaSettingType. This allows to find the setting-data by simple
  pointer arithmetic, instead of taking a look and iterating (like
  g_type_set_qdata() does).

  Note, that this is still thread safe, because the static table entry is
  initialized in the class-init function with _nm_setting_class_commit().
  And it only accessed by following a NMSettingClass instance, thus
  the class constructor already ran (maybe not for all setting classes,
  but for the particular one that we look up).

  I think this makes initialization of the metadata simpler to
  understand.
  Previously, in a first phase each class would attach the metadata
  to the GType as setting_property_overrides_quark(). Then during
  nm_setting_class_ensure_properties() it would merge them and
  set as setting_properties_quark(). Now, during the first phase,
  we only incrementally build a properties_override GArray, which
  we finally hand over during nm_setting_class_commit().

- sort the property infos by name and do binary search.

Also expose this meta data types as internal API in nm-setting-private.h.
While not accessed yet, it can prove beneficial, to have direct (internal)
access to these structures.

Also, rename NMSettingProperty to NMSettInfoProperty to use a distinct
naming scheme. We already have 40+ subclasses of NMSetting that are called
NMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a
new, distinct name.
2018-08-10 10:38:19 +02:00
Thomas Haller
9c47e2ce30 libnm: use NMMetaSettingInfo for tracking setting priority
Previously, each (non abstract) NMSetting class had to register
its name and priority via _nm_register_setting().

Note, that libnm-core.la already links against "nm-meta-setting.c",
which also redundantly keeps track of the settings name and gtype
as well.

Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta
data.

The goal is to get rid of private data structures that track
meta data about NMSetting classes. In this case, "registered_settings"
hash. Instead, we should have one place where all this meta data
is tracked. This was, it is also accessible as internal API,
which can be useful (for keyfile).

Note that NMSettingClass has some overlap with NMMetaSettingInfo.
One difference is, that NMMetaSettingInfo is const, while NMSettingClass
is only initialized during the class_init() method. Appart from that,
it's mostly a matter of taste, whether we attach meta data to
NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed
by NMMetaSettingType.

Note, that previously, _nm_register_setting() was private API. That
means, no user could subclass a functioning NMSetting instance. The same
is still true: NMMetaSettingInfo is internal API and users cannot access
it to create their own NMSetting subclasses. But that is almost desired.
libnm is not designed, to be extensible via subclassing, nor is it
clear why that would be a useful thing to do. One day, we should remove
the NMSetting and NMSettingClass definitions from public headers. Their
only use is subclassing the types, which however does not work.

While libnm-core was linking already against nm-meta-setting.c,
nm_meta_setting_infos was unreferenced. So, this change increases
the binary size of libnm and NetworkManager (1032 bytes). Note however
that roughly the same information was previously allocated at runtime.
2018-08-10 10:38:19 +02:00
Thomas Haller
23adc37377 libnm/trivial: cleanup variable names in settings' class-init functions
- Don't use @parent_class name. This local variable (and @object_class) is
  the class instance up-cast to the pointer types of the parents. The point
  here is not that it is the direct parent. The point is, that it's the
  NMSettingClass type.
  Also, it can only be used inconsistently, in face of NMSettingIP4Config,
  who's parent type is NMSettingIPConfig. Clearly, inside
  nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
  name. Consistently rename @parent_class to @setting_class.

- Also rename the pointer to the own class to @klass. "setting_class" is also the
  wrong name for that, because the right name would be something like
  "setting_6lowpan_class".
  However, "klass" is preferred over the latter, because we commonly create new
  GObject implementations by copying an existing one. Generic names like "klass"
  and "self" inside a type implementation make that simpler.

- drop useless comments like

     /* virtual functions */
     /* Properties */

  It's better to logically and visually structure the code, and avoid trival
  remarks about that. They only end up being used inconsistently. If you
  even need a stronger visual separator, then an 80 char /****/ line
  should be preferred.
2018-08-10 10:38:19 +02:00
Beniamino Galvani
d3db846d95 ifcfg-rh: add missing NM-only annotations
Add the (+) annotation to NM-only variables.
2018-07-11 16:16:22 +02:00
Thomas Haller
fa9fe466db libnm: avoid constructor function for registering NMSetting types
constructor functions are ugly, because code is running before
main() starts. Instead, as the registration code for NMSetting types
is insid the GType constructor, we just need to ensure at the
right place, that the GType was created.

The right place here is _register_settings_ensure_inited(), because
that is called before we need the registration information.
2018-07-01 18:17:31 +02:00
Francesco Giudici
f913ed4d0c ifcfg: introduce DHCPV6_DUID to map ipv6.dhcp-duid property 2018-06-09 22:20:39 +02:00
Francesco Giudici
7a0b6b17bb libnm-core: add ipv6.dhcp-duid property
allow to specify the DUID to be used int the DHCPv6 client identifier
option: the dhcp-duid property accepts either a hex string or the
special values "lease", "llt", "ll", "stable-llt", "stable-ll" and
"stable-uuid".

"lease": give priority to the DUID available in the lease file if any,
         otherwise fallback to a global default dependant on the dhcp
         client used. This is the default and reflects how the DUID
         was managed previously.
"ll": enforce generation and use of LL type DUID based on the current
      hardware address.
"llt": enforce generation and use of LLT type DUID based on the current
       hardware address and a stable time field.
"stable-ll": enforce generation and use of LL type DUID based on a
             link layer address derived from the stable id.
"stable-llt": enforce generation and use of LLT type DUID based on
              a link layer address and a timestamp both derived from the
              stable id.
"stable-uuid": enforce generation and use of a UUID type DUID based on a
               uuid generated from the stable id.
2018-06-08 18:23:31 +02:00
Beniamino Galvani
1b5925ce88 all: remove consecutive empty lines
Normalize coding style by removing consecutive empty lines from C
sources and headers.

https://github.com/NetworkManager/NetworkManager/pull/108
2018-04-30 16:24:52 +02:00
Francesco Giudici
0ed5cd5442 libnm-core: trivial: fix indentation 2018-03-26 18:03:07 +02:00
Beniamino Galvani
a9b5079324 ifcfg-rh: use separate variables for DNS searches
DNS searches from the ipv4 and ipv6 settings were joined and written
to the same ifcfg-rh "DOMAIN" variable and so the connection read back
from disk was different from the one written.

Instead, introduce a separate variable for ipv6 searches; to preserve
backwards compatibility, still read the "DOMAIN" variable for ipv6
when ipv4 is disabled so that we don't lose DNS searches on upgrade.

https://bugzilla.redhat.com/show_bug.cgi?id=1517794
2017-12-07 09:58:09 +01:00
Beniamino Galvani
8379785560 ifcfg-rh: use different variables for IPv4 and IPv6 DNS options
Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options'
and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS
variable. This is wrong because writing a connection and reading it
back gives a different connection compared to the original.

This behavior existed since when DNS options were introduced, but it
became more evident now that we reread the connection after write,
because after doing a:

 $ nmcli connection modify ethie ipv4.dns-options ndots:2

the connection has both ipv4.dns-options and ipv6.dns-options set. In
order to delete the option, an user has to delete it from both
settings:

 $ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options ""

To improve this let's use different variables for IPv4 and IPv6. To
keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6
uses a new IPV6_RES_OPTIONS variable.

https://bugzilla.redhat.com/show_bug.cgi?id=1517794
2017-11-30 23:54:45 +01:00
Beniamino Galvani
a30ce8086d libnm-core: specify enum values in NMSettingIP6Config:addr-gen-mode doc
So that the man page will display:

  The permitted values are: NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64
  (0) or NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY (1).

instead of

  The permitted values are: "eui64" or "stable-privacy".

since the latter is not useful at all for a int32 property.
Unfortunately the enum names are quite long and don't look very well
in a table, but that's another problem.
2017-10-13 12:04:41 +02:00
Thomas Haller
cc1ee1d286 all: rework configuring route table support by adding "route-table" setting
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.

These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.

As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.

The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.

For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
2017-10-09 22:05:36 +02:00
Thomas Haller
c71f26bf92 libnm,cli: add IP setting "route-table-sync" 2017-09-26 19:39:36 +02:00
Thomas Haller
752afada0b docs: fix spelling errors in tranlated strings and documentation
https://bugzilla.gnome.org/show_bug.cgi?id=786131
2017-08-11 11:05:12 +02:00
Thomas Haller
488029d74b libnm: use enum for setting priorities 2017-06-07 09:07:17 +02:00
Lubomir Rintel
7b5712acd2 core: allow two priorities of base settings
We'll need two "base" settings for Bluetooth NAP connections: bridge to set up
the actual link and bluetooth to identify the HCI to register the network
server with.

Let's use two priorities for base setting, with "1" marking one of higher
priority and "2" of lower priority when both are present.
2017-05-31 20:15:01 +02:00
Thomas Haller
255bc928d7 libnm: fix error message for invalid ipv6.addr-gen-mode 2017-03-30 10:19:13 +02:00
Thomas Haller
f0d40525df device: support dynamic "connection.stable-id" in form of text-substitution
Usecase: when connecting to a public Wi-Fi with MAC address randomization
("wifi.cloned-mac-address=random") you get on every re-connect a new
IP address due to the changing MAC address.
"wifi.cloned-mac-address=stable" is the solution for that. But that
means, every time when reconnecting to this network, the same ID will
be reused. We want an ID that is stable for a while, but at a later
point a new ID should e generated when revisiting the Wi-Fi network.

Extend the stable-id to become dynamic and support templates/substitutions.
Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}".
Any unrecognized pattern is treated verbaim/untranslated.

"$$" is treated special to allow escaping the '$' character. This allows
the user to still embed verbatim '$' characters with the guarantee that
future versions of NetworkManager will still generate the same ID.
Of course, a user could just avoid '$' in the stable-id unless using
it for dynamic substitutions.

Later we might want to add more recognized substitutions. For example, it
could be useful to generate new IDs based on the current time. The ${} syntax
is extendable to support arguments like "${PERIODIC:weekly}".

Also allow "connection.stable-id" to be set as global default value.
Previously that made no sense because the stable-id was static
and is anyway strongly tied to the identity of the connection profile.
Now, with dynamic stable-ids it gets much more useful to specify
a global default.

Note that pre-existing stable-ids don't change and still generate
the same addresses -- unless they contain one of the new ${} patterns.
2017-01-09 14:50:33 +01:00
Lubomir Rintel
0e6d194060 settings: allow method=shared with manual IPv6 configuration
IPv4 already allows setting an address, reusing its prefix for the network
it shares connection with. Additionally, for IPv6, the NDP can also share
the DNS configuration.
2016-11-09 17:23:32 +01:00
Beniamino Galvani
ac73758305 libnm-core: ip-config: normalize may-fail for disabled IP methods
Since commit 7d1709d7f6 ("device: check may_fail when progressing to
IP_CHECK") NM correctly checks the may-fail properties to decide
whether a connection must fail after the completion of IP
configuration. But for ipv4.method=disabled and ipv6.method=ignore the
IP configuration is always considered failed and thus setting
may-fail=no results in a connection that can never succeed.

To prevent such wrong configuration, force may-fail to TRUE for those
methods during connection normalization.

https://bugzilla.redhat.com/show_bug.cgi?id=1334884
2016-07-06 09:52:35 +02:00
Lubomir Rintel
954d937b2f setting-ip6-config: add token property 2016-05-30 16:32:06 +02:00
Beniamino Galvani
c5f17531b9 ifcfg-rh: add support for DNS priority 2016-05-12 17:13:50 +02:00
Thomas Haller
bad9becf99 libnm/doc: fix documentation of NMSettingIP6Config:addr-gen-mode
The value cannot be unset. It must be set to one of the two currently
supported values.
2016-04-25 16:52:34 +02:00
Thomas Haller
737c8cc532 libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus()
In some situations, we want strict checking of errors, for example when
NetworkManager receives a new connection from a client, the connection
must make sense as a whole (and since NetworkManager service is backward
compatible to the clients and not the other way around, there is no
excuse for sending invalid data to the server).

In other situations, we want a best-effort behavior. Like when
NetworkManager sends a connection to its clients, those clients
want to extract as many properties as they understand, but in order
to be forward compatible against newer server versions, invalid
or unknown properties must be accepted.

Previously, a mixture of both was done. Some issues caused a failure
to create a new NMSetting, other invalid parts were just silently
ignored or triggered a g_warning() in glib.

Now allow for both. When doing strict-validation, be more strict and
reject all unknown properties and catch when the user sets an invalid
argument. On the other hand, allow for a best-effort mode that
effectively cannot fail and will return a new NMSetting instance.

For now, add NMSettingParseFlags so that the caller can choose the
old behavior, strict parsing, or best effort.

This patch doesn't have any externally visible change except that
no more g_warnings will be emitted.
2016-03-26 12:10:54 +01:00
Thomas Haller
8bace23beb all: cleanup includes and let "nm-default.h" include "config.h"
- All internal source files (except "examples", which are not internal)
  should include "config.h" first. As also all internal source
  files should include "nm-default.h", let "config.h" be included
  by "nm-default.h" and include "nm-default.h" as first in every
  source file.
  We already wanted to include "nm-default.h" before other headers
  because it might contains some fixes (like "nm-glib.h" compatibility)
  that is required first.

- After including "nm-default.h", we optinally allow for including the
  corresponding header file for the source file at hand. The idea
  is to ensure that each header file is self contained.

- Don't include "config.h" or "nm-default.h" in any header file
  (except "nm-sd-adapt.h"). Public headers anyway must not include
  these headers, and internal headers are never included after
  "nm-default.h", as of the first previous point.

- Include all internal headers with quotes instead of angle brackets.
  In practice it doesn't matter, because in our public headers we must
  include other headers with angle brackets. As we use our public
  headers also to compile our interal source files, effectively the
  result must be the same. Still do it for consistency.

- Except for <config.h> itself. Include it with angle brackets as suggested by
  https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 17:53:25 +01:00
Thomas Haller
2c2d9d2e4c build: cleanup default includes
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
  "nm-default.h". No need to include them separately.

- include "nm-macros-internal.h" via "nm-default.h" and drop all
  explict includes.

- in the modified files, ensure that we always include "config.h"
  and "nm-default.h" first. As second, include the header file
  for the current source file (if applicable). Then follow external
  includes and finally internal nm includes.

- include nm headers inside source code files with quotes

- internal header files don't need to include default headers.
  They can savely assume that "nm-default.h" is already included
  and with it glib, nm-glib.h, nm-macros-internal.h, etc.
2016-02-12 15:36:01 +01:00
Lubomir Rintel
e9dfdfe9fe libnm-core: default to ip6.addr-gen-mode=stable-privacy
Take a missing value in keyfile/ifcfg-rh as EUI-64 to keep the compatibility
with the old conneciton. Nevertheless, the new connections should default to
the RFC7217 addresses.
2015-11-02 20:27:36 +01:00
Lubomir Rintel
60811b4809 setting-ip6-config: add addr-gen-mode property 2015-11-02 20:27:00 +01:00
Jiří Klimeš
12e6cf1f20 libnm-core/libnm-util: fix an erroneous error message
ipv6.dns: 'this property is not allowed for '%s=%s'' not allowed for method=ignore
2015-09-25 16:11:24 +02:00
Dan Winship
22e1a97e12 all: drop includes to <glib/gi18n.h> for "nm-default.h"
The localization headers are now included via "nm-default.h".

Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
2015-08-05 15:35:51 +02:00
Thomas Haller
f3c61f8141 device: remove reading ipv6 privacy setting from sysctl
Since introduction for support of ip6-privacy (use_tempaddr,
RFC4941) with commit d376270bfe,
the sysctl value from /etc was always read first.

This is problematic, because an explicit setting in the
connection should not be ignored over a global configuration.

Drop that old behavior. It was also problematic, because we did
not read any files under /etc/sysctl.d (except for sysctl.conf).
Also, we did not honor per-interface configurations.

Now we also use as last fallback the value from
/proc/sys/net/ipv6/conf/default/use_tempaddr
That has the advantage of falling back to the system default value
so that NM doesn't need to have it's own default policy
(Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525).

This is a change in behavior.
2015-06-05 12:38:30 +02:00
Thomas Haller
e729dd70ae device: add global configuration default for ip6-privacy (use_tempaddr, RFC4941)
Support default value for setting 'ipv6.ip6-privacy' in
NetworkManager.conf.

If the global value is unset, preserve old behavior of looking into
/etc/sycctl.conf first. That behavior was introduced with commit
d376270bfe, since we support ip6-privacy
setting.

If the global value is set to "unknown", add a new fallback
that instead reads the runtime value from
  "/proc/sys/net/ipv6/conf/default/use_tempaddr"
This seems more sensible behavior because we fallback to sysctl,
but instead of looking at static files in /etc, read /proc.
But to preserve the old behavior, we only do that when a global
value is configured at all.

https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-06-05 12:38:30 +02:00
Thomas Haller
e4293788fc libnm/doc: document behavior of setting ip6-privacy in /etc/sysctl.conf
https://bugzilla.gnome.org/show_bug.cgi?id=721200
2015-06-05 12:38:30 +02:00
Thomas Haller
3e33a5a6c5 ifcfg-rh: support ipvx.route-metric property as IPVX_ROUTE_METRIC
Write ipv4.route-metric and ipv6.route-metric property of
NMSettingConnection as IPV4_ROUTE_METRIC and IPV6_ROUTE_METRIC,
respectively.
2015-01-10 21:10:52 +01:00
Jiří Klimeš
485edd52a7 libnm-core: update ip6-privacy ifcfg-rh description 2014-11-19 09:24:10 -05:00
Jiří Klimeš
a244e61688 libnm-core: update documentation of addresses and gateway properties 2014-11-19 09:24:10 -05:00
Dan Winship
36156b70dc libnm: Override parts of nm-setting-docs.xml
Add "---dbus---" sections to the NMSetting property docs, in the same
style as the plugin docs, parse them out into a file
"nm-setting-docs-overrides.xml", and use them to override the GObject
property docs in nm-setting-docs.xml.

This lets us put more D-Bus-specific information in the setting docs,
without cluttering up the property docs, and it also lets us document
dbus-only properties.
2014-11-19 09:24:10 -05:00
Dan Winship
c14486984e libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.

With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).

The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...

(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-11-19 09:24:09 -05:00
Dan Winship
c785a7dfcd libnm-core: change how new and legacy properties are serialized
Although libnm filters out properties received from the daemon that it
doesn't understand, there may be other clients that do not. In
particular, a client might call GetSettings() on a connection, update
the ipv4.addresses property in the returned dictionary, and then pass
the dictionary to Update(). In that case, the updated dictionary would
contain ipv4.address-data, but it would not reflect the changes the
client intended to make.

Fix this by changing the daemon side to prefer the legacy properties
to the new ones if both are set, and changing the client side to not
send the legacy properties (since we don't support new clients talking
to old servers anyway).
2014-11-15 09:52:29 -05:00
Dan Winship
53f5e9afa4 libnm*: fix library gettext usage
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).

(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
2014-11-13 17:18:42 -05:00
Dan Winship
3bfb163a74 all: consistently include config.h
config.h should be included from every .c file, and it should be
included before any other include. Fix that.

(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
2014-11-13 17:18:42 -05:00
Dan Winship
d16905df63 libnm-core, libnm, core: add AddressData and RouteData properties
Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.

This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.

NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.

The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
2014-11-07 07:49:40 -05:00
Dan Winship
f17699f4e3 libnm-core: add NMSettingIPConfig:gateway, drop NMIPAddress:gateway
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.

Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.

Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
2014-11-07 07:49:40 -05:00
Dan Winship
3f30c6f1c2 libnm-core: extract NMSettingIPConfig superclass out of IP4, IP6 classes
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.

Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
2014-11-07 07:49:40 -05:00
Dan Winship
21c8a6b20e libnm-core, all: merge IPv4 and IPv6 address/route types
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
2014-11-07 07:49:40 -05:00
Dan Winship
9e5c7d915b libnm-core: make nm_setting_verify() take an NMConnection
nm_setting_verify() took a GSList of other NMSettings, but really it
would just be simpler all around to pass the NMConnection instead...

This means that several formerly NMSetting-branded functions that
operated on lists-of-settings now get replaced with
NMConnection-branded functions instead.
2014-10-28 17:17:17 -04:00
Dan Winship
2d8e7bd247 libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.

So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)

Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.

Renamed error codes:

NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET

Remapped error codes:

NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY

Dropped error codes (were previously defined but unused):

NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-22 08:29:07 -04:00
Dan Winship
fcfb4b40ba libnm: make use of GParamSpecFlags and GParamSpecEnum
Make enum- and flags-valued properties use GParamSpecEnum and
GParamSpecFlags, for better introspectability/bindability.

This requires no changes outside libnm-core/libnm since the expected
data size is still the same with g_object_get()/g_object_set(), and
GLib will internally convert between int/uint and enum/flags GValues
when using g_object_get_property()/g_object_set_property().
2014-10-03 09:36:28 -04:00
Dan Winship
acf86f68b3 libnm-core: change connection hash tables to variants in API
In preparation for porting to GDBus, make nm_connection_to_dbus(),
etc, represent connections as GVariants of type 'a{sa{sv}}' rather
than as GHashTables-of-GHashTables-of-GValues.

This means we're constantly converting back and forth internally, but
this is just a stepping stone on the way to the full GDBus port, and
all of that code will go away again later.
2014-09-18 11:51:09 -04:00