Since libnm-util is no longer used from within NM, its copy of
NM_UTIL_PRIVATE_CALL is now useless, and the internal-only
NMSettingIP4Config:address-labels property is no longer needed.
- Remove list of authors from files that had them; these serve no
purpose except to quickly get out of date (and were only used in
libnm-util and not libnm-glib anyway).
- Just say "Copyright", not "(C) Copyright" or "Copyright (C)"
- Put copyright statement after the license, not before
- Remove "NetworkManager - Network link manager" from the few files
that contained it, and "libnm_glib -- Access network status &
information from glib applications" from the many files that
contained it.
- Remove vim modeline from nm-device-olpc-mesh.[ch], add emacs modeline
to files that were missing it.
Remove all the GParamSpec docs, since everything now uses the gtk-doc
docs instead, so there's no point in having two copies of each (which
are often out of sync anyway).
Since we're touching so many lines anyway, also fix up the indentation
of the remaining property-installing lines, and add
G_PARAM_STATIC_STRINGS to each paramspec (so the nick strings don't
get strduped). Also, be consistent about starting a new line between
"g_object_class_install_property" and its opening parenthesis.
Fix up various issues with the docs for the NMSetting properties, and
pull in text from the GParamSpec docs where the GParamSpec docs were
better (or contained information that is necessary in the context of
nm-settings.5).
Also, consistently wrap all of the doc comments to the same width (80
columns).
Fix misused gtk-doc annotations and incorrectly-identified properties.
In particular, the upcoming introspection-based generate-settings-spec
expands macro and enum values, so if you use '%' where you should have
used '#', it will fail to find an expansion, and error out.
ipv4.never-default, ipv4.may-fail, and ipv6.privacy were marked
INFERRABLE, but NMIP4Config / NMIP6Config didn't actually infer them,
so they could cause connections to not match themselves after a
restart.
(Found while debugging https://bugzilla.redhat.com/show_bug.cgi?id=1086237,
though this is not actually the problem there.)
Related: rh#1086237
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
- refactor register_settings to allow lookup by GType and
add the settings name to SettingInfo.
- setting NM_SETTING_NAME is deprecated and should not be set anymore.
Indeed it has always be a bug, to reset the name to a different value.
The only valid place to set the name was in the _init() function of
the derived class itself.
This is now no longer needed/possible. Instead the name get's
detected based on the registered setting types. This makes use of
the registered metadata that is available anyway since every
usable setting has to register itself.
Signed-off-by: Thomas Haller <thaller@redhat.com>
It is better to leave it to user whether he wants to enable sending hostname,
because he probably disabled it manually (dhcp-send-hostname is TRUE by default).
Also, this would not work for plugins that read and set dhcp-hostname after
dhcp-send-hostname.
https://bugzilla.redhat.com/show_bug.cgi?id=1001529
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
If BOOTPROTO is set to "none", user states that no ipv4 setting should
be set. So respect that.
Introduce helper is_any_ip4_address_defined() along the way to make the
code more readable.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
(comments by dcbw)
This allows out-of-the-box connectivity on IPv6-only networks.
Once caveat is that connections where the user currently
expects no IPv4 connectivity to terminate the connection and
retry will no longer do so until IPv6 also times out, and if
that network where IPv4 is expected to fail also has an IPv6
router sending advertisements, the connection will succeed
instead of failing. That can be resolved by setting the
right bit in the connection's config file; and it's expected
that the number of users who expect IPv4 failure on a
network with usable IPv6 connectivity is quite small
compared to the benefit of OOB IPv6 connectivity.
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
Add the necessary annotations (the mininum required, that is those
on return values. NULL parameters or container types may require
more), and the Autotools stuff to get a NetworkManager GIR for
libnm-util and a NMClient for libnm-glib.
When this property is TRUE, IP configuration can continue as long
as at least on IP configuration type succeeds. This allows
connections to networks where the user does not necessarily know
whether the network supports IPv4 or IPv6 and does not require
that both complete succesfully.
Since most of the time the user doesn't really care what type
of connectivity they have, as long as they have *some* connectivity,
this allows better "Just Works" behavior as long as the system
settings plugins and connection editors/applets use the right
defaults.
Suggested defaults for may-fail are:
IPv4: no (ie, require IPv4 connectivity)
IPv6: yes (ie, do not require IPv6 connectivity)
Users who require a specific type of connectivity are probably
knowlegable enough to check the box as needed for their network.
This caused the 'autoconnect' property of NMSettingConnection to not
get updated in some cases (as when a system setting plugin noticed a
change to autoconnect=true and emitted the Updated signal, which wouldn't
contain the new value). Add a testcase for setting default values too.
* 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
