Instead of creating it in NMSettings, where we must use
NM_IS_DEVICE_ETHERNET() (not NM_DEVICE_TYPE_ETHERNET because various generic
devices masquerade as NM_DEVICE_TYPE_ETHERNET too), push knowledge
of which device types create default wired connections into the device
types themselves. This solves a problem with testcases where
libNetworkManager.a (which testcases link to) requires the symbol
nm_type_device_ethernet().
Change all DBUS_TYPE_G_LIST_OF_STRING and DBUS_TYPE_G_ARRAY_OF_STRING
properties to G_TYPE_STRV, and update everything accordingly.
(This doesn't actually require using
_nm_setting_class_transform_property(); dbus-glib is happy to transform
between 'as' and G_TYPE_STRV.)
The fact that NMRemoteConnection has to be an NMConnection and
therefore can't be an NMObject means that it needs to reimplement bits
of NMObject functionality (and likewise NMObject needs some special
magic to deal with it). Likewise, we will need a daemon-side
equivalent of NMObject as part of the gdbus port, and we would want
NMSettingsConnection to be able to inherit from this as well.
Solve this problem by making NMConnection into an interface, and
having NMRemoteConnection and NMSettingsConnection implement it. (We
use some hacks to keep the GHashTable of NMSettings objects inside
nm-connection.c rather than having to be implemented by the
implementations.)
Since NMConnection is no longer an instantiable type, this adds
NMSimpleConnection to replace the various non-D-Bus-based uses of
NMConnection throughout the code. nm_connection_new() becomes
nm_simple_connection_new(), nm_connection_new_from_hash() becomes
nm_simple_connection_new_from_hash(), and nm_connection_duplicate()
becomes nm_simple_connection_new_clone().
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
Include <linux/if_ether.h> and <linux/if_infiniband.h> from
nm-utils.h, to get ETH_ALEN and INFINIBAND_ALEN, and remove those
includes (as well as <net/ethernet.h> and <netinet/ether.h>, and
various headers that had been included to get the ARPHRD_* constants)
from other files where they're not needed now.
Drop the arptype-based nm_utils_hwaddr funcs, and rename the
length-based ones to no longer have _len in their names. This also
switches nm_utils_hwaddr_atoba() to using a length rather than an
arptype, and adds a length argument to nm_utils_hwaddr_valid() (making
nm_utils_hwaddr_valid() now a replacement for nm_utils_hwaddr_aton()
in some places, where we were only using aton() to do validity
checking).
Add NetworkManager.h, which includes all of the other NM header, and
require all external users of libnm to use that rather than the
individual headers.
(An exception is made for nm-dbus-interface.h,
nm-vpn-dbus-interface.h, and nm-version.h, which can be included
separately.)
Since the API has not changed at this point, this is mostly just a
matter of updating Makefiles, and changing references to the library
name in comments.
NetworkManager cannot link to libnm due to the duplicated type/symbol
names. So it links to libnm-core.la directly, which means that
NetworkManager gets a separate copy of that code from libnm.so.
Everything else links to libnm.
gcc warns:
make[4]: Entering directory `./NetworkManager/libnm-util'
CC nm-value-transforms.lo
nm-value-transforms.c: In function '_nm_utils_convert_op_array_to_string':
nm-value-transforms.c:121:6: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (i > 0)
^
nm-value-transforms.c: In function '_nm_utils_convert_string_array_to_string':
nm-value-transforms.c:121:6: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (i > 0)
^
make[7]: Entering directory `./NetworkManager/src/settings/plugins/ifcfg-rh'
CC reader.lo
reader.c: In function 'make_wired_setting':
reader.c:3295:6: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (!found)
^
reader.c: In function 'wireless_connection_from_ifcfg':
reader.c:3295:6: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (!found)
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some subdirectories of src/ encapsulate large chunks of functionality,
but src/config/, src/logging/, and src/posix-signals/ are really only
separated out because they used to be built into separate
sub-libraries that were needed either for test programs, or to prevent
circular dependencies. Since this is no longer relevant, simplify
things by moving their files back into the main source directory.
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
5b4be27f moved test-dhcp-options from src/tests/ to
src/dhcp-manager/tests/, but src/tests/Makefile.am still included it
in "TESTS" (which would still work until you tried to build from a
clean tree...)
Previously the tests required that a NMDHCPClient object was
created, but all that's really being tested is the DHCP option
parsing and that doesn't need a client object now that the
option parsing has been split out.
Also, the options test wasn't in src/dhcp-manager/, so put it there.
Lastly, the test ran for both dhclient and dhcpcd, but the code
executed for both cases was the same, so there's no reason to keep
running the test for both clients.
nm-version.h was getting disted, making srcdir!=builddir work for
tarball builds, but not for git builds.
Also, remove "-I${top_builddir}/include" from all Makefile.ams, since
there's nothing generated in include/ any more.
Some tests want to assert against the messages logged using g_test_expect_message().
In this mode, nmtst will not log anything itself.
Interpret the option no-expect-message which turns g_test_expect_message()
into a NOP and turns logging on. The use of this is for debugging such
tests, without asserting against the messages but printing them instead.
For tests that are not in the assert_message mode, the option has no
effect.
Example:
NMTST_DEBUG=debug,no-expect-message make -C src/settings/plugins/keyfile/tests/ check
Signed-off-by: Thomas Haller <thaller@redhat.com>
In this mode, nmtst itself will not log anything and not set the logging
level. Also, it will set g_log_set_always_fatal().
This is for tests that want to assert against all logged messages via
g_test_expect_message().
In this mode also setting the logging level via NMTST_DEBUG variable has
no effect. The test is expected to manage the logging level itself and
changing the logging level might interfere with the test.
As a showcase, move keyfile/tests/test-keyfile.c to nmtst.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If we had a connection with IPv6.method = ignore, we simply ignored IPv6. So
we should assume this connection even if there is an SLAAC address on the
interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1083196
Make Wi-Fi support a plugin using the new device factory interface.
Provides a 7% size reduction in the core NM binary.
Before After
NM: 1154104 1071992 (-7%)
Wi-Fi: 0 110464
(all results from stripped files)
NetworkManager stopped touching /etc/hosts in late 2010 before the
NetworkManager 0.8.1 release. The code in nm-policy-hosts.c's only
purpose is to remove any of the entries that NetworkManager added long
ago.
I think we're at the point where people have already upgraded to
NetworkManager 0.8.1 or later and thus this code would be a NOP. The
only risk is that some stale /etc/hosts entries will be left if you
upgrade from NM 0.8 or lower to anything higher than that.
FWIW, Ubuntu Lucid (10.04) ships NM 0.8.0 and SLES11 ships NM 0.7.0, so
if users of these distros upgraded to a later NetworkManager they might
run into the stale entries issue if we remove this code from NM. But
given how old these distros are, it seems unlikely that users will do a
direct upgrade to something 4+ years newer...
https://bugzilla.gnome.org/show_bug.cgi?id=729689
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>
Use g_test_expect_message() in the various daemon-side test programs,
to avoid spewing error messages when (successfully) running "make
check".
The ifnet and ifupdown plugins are extremely verbose, so they were
partially "fixed" by turning down the logging level from INFO to WARN
in those tests.
test-dhcp-options needed to be converted to gtestutils so that the
newly-added check in nm-dbus-manager would recognize it as a test
program and not try to create a private bus.
Clients such as gnome-control-center or nm-applet show
at some places only one (IPv6) address. They most likely
just pick the first address from the list of addresses,
so we should order them.
Sorting has the advantage to make the order deterministic --
contrary to before where the order depended on run time conditions.
Note, that it might be desirable to show the address that the kernel
will use as source address for new connections. However, this depends
on routing and cannot be easily determined in general. Still, the
ordering tries to account for this and sorts the addresses accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=726525
Signed-off-by: Thomas Haller <thaller@redhat.com>
No need to allocate a dynamic buffer in most of the cases.
And extended test cases to test with/without white space
and leading zeros.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Non-git-master versions of lldpad refuse to touch a device that doesn't
have a carrier. And when enabling/disabling DCB, the kernel driver will
reconfigure itself and may turn carrier off for a few seconds. So we
must ensure that before enabling/disabling DCB, the carrier is already
on. Next we must ensure that *after* enabling/disabling DCB, the
carrier is back on before doing further DCB setup.
There's a race condition between enabling/disabling DCB and receiving
the carrier event in NetworkManager that has to be handled carefully.
Because the carrier may not yet be down after the dcbtool call to
enable/disable DCB returns, we need to wait for a couple seconds for
the carrier to go down, and then again for it to come back up.
Otherwise we might see the still-on carrier, proceed with DCB setup,
and the carrier finally goes down halfway through the setup, which
will fail the operations with "DCB not enabled, link down, or DCB
not supported" errors from lldpad.
