This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit 240c92ddb5 added an assert
to check that the input netmask is valid. Revert that commit for
the most part, some changes to the test function are not reverted.
We don't want to assert for a valid netmask, because it's
common to read the netmask from (untrusted) user input, so we
don't want to assert against it.
The caller *could* validate the netmask from untrusted sources, but
with the assert in place it cannot validate it in the most obvious way:
prefix = nm_utils_ip4_netmask_to_prefix (netmask);
if (netmask != nm_utils_ip4_prefix_to_netmask (prefix))
goto fail;
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
- use a more efficient implementation for prefix_to_netmask
- fix netmask_to_prefix to behave consistently in case of
invalid netmask
- remove unused duplicated functions from NetworkManagerUtils.c
- add test functions
Based-on-patch-by: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771
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.
Old versions such as 0.9.4 generated 40-character UUIDs with no
hashes, but libnm-util regards them as invalid. That means that
existing connections stop working when upgrading from 0.9.4.
Continue accepting such UUIDs as valid, and add a test so that
we don't forget in future.
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
4d326182 changed connection hashing slightly such that now base type settings
are always returned even if they are empty. Unfortunately a bunch of code in
the settings hashed connections with the ONLY_SECRETS flag and then checked
whether the returned hash was NULL or not to determine whether there were
any secrets, and then called nm_connection_update_secrets() with the hash.
nm_connection_update_secrets() would fail in the case where a setting
name was given, but the passed-in secrets hash did not contain any secrets
for the requested setting. Instead, the function should return success
to match the semantics of passing in an entire connection hash which may
not have any secrets either.
Convenience function to replace settings in one conneciton with settings
from another, without having to go through the nm_connection_to_hash()
steps, which are just inefficient and kinda pointless.
Avoid warnings about GValueArray being deprecated by adding macros
that wrap G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS around the GValueArray calls.
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
g_malloc(), etc, never return NULL, by API contract. Likewise, by
extension, no other glib function ever returns NULL due to lack of
memory. So remove lots of unnecessary checks (the vast majority of
which would have immediately crashed had they ever run anyway, since
g_set_error(), g_warning(), and nm_log_*() all need to allocate
memory).
https://bugzilla.gnome.org/show_bug.cgi?id=693678
Use --enable-doc and --enable-tests instead of --with-docs and
--with-tests. This is consistent with other features and with
--enable-gtk-doc option. Support current variants as fallback.
Don't build tests unless --enable-tests is specified.
ether_aton() allows addresses like "0:1:2:3:4:5" which was casusing
some problems when reading connections after switching callers of
ether_aton() to nm_utils_hwaddr_aton().
The core problem was that the Update would trigger a write to
disk to save the connection's new settings, which called
nm_settings_connection_replace_settings(). Which saved existing
transient (agent/unsaved) secrets, replaced settings with the
new ones from Update(), then copied back the old transient
secrets. This was to ensure that changes triggered from getting
agent secrets during activation (which might write the connection
out to disk if new system secrets were provided, which triggered
an inotify read-back of the connection, which blew away the
transient secrets just returned from the agent) didn't blow away
transient secrets. Unfortunately that fix was too general.
As a quick hack for now, copy the new secrets and re-apply them
after nm_connection_replace_settings() has run. We'll do the
actual fix later, but it's more involved and needs more testing
so we don't want to apply it this close to release.
"mac-address-blacklist" property is added to the ethernet and WiFi connections.
It is the MAC addresses list of devices on which the connection won't be
activated.
Original patch (NM_0_8 branch) from Thomas Bechtold <thomasbechtold@jpberlin.de>
It turns out we need a way to ignore transient (agent-owned or unsaved)
secrets during connection comparison. For example, if the user is
connecting to a network where the password is not saved, other
changes could trigger a writeout of that connection to disk when
connecting, which would the connection back in due to inotify, and the
re-read connection would then no longer be recognized as the same as
the in-memory connection due to the transient secret which obviously
wasn't read in from disk.
Adding these compare flags allows the code to not bother writing the
connection out to disk when the only difference between the on-disk
and in-memory connections are secrets that shouldn't get written to
disk anyway.
The ETSI specs state that valid characters are only ASCII alphanumeric
characters, but then state that APNs should generally follow DNS
naming rules. Well, that means a lot more characters are allowed,
but modems don't like many of them. So let's slowly allow more
characters as people find ones that actually are used. The restriction
was originally put in place to disallow spaces, because they
certainly aren't allowed APN characters and modems and the
network puke when they see spaces.
