Add new macro nm_log_obj() to prefix the log line with a pointer value
as identifier. This macro can be used to give each logging line a common
prefix with defined format. It is mainly intended to print a message
"for" an object, for example inside a method function.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Change the definition of nm_log() to first check whether logging is
enabled. This has the benefit, that the logging arguments don't have
to be evaluated if logging is disabled.
With this change, you must ensure, that calling any logging function
is side-effect-free. For example:
nm_log_debug ("This is a bug %s, %d", has_side_effect (), ++i);
would be a bug, because the logging arguments get only evaluated
depending on the logging setup.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Base the definition of nm_log_*() macros on the nm_log() macro,
instead of directly on the _nm_log() function.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Ensure that nm_logging_setup() was called for all functions
where it actually makes a difference.
This is especially important for nm_logging_enabled(),
so that the behavior of the following is identical:
nm_log_info(LOGD_CORE, "hello world");
and
if (nm_logging_enabled (LOGL_INFO, LOGD_CORE))
nm_log_info(LOGD_CORE, "hello world");
Signed-off-by: Thomas Haller <thaller@redhat.com>
Out-of-tree build fails with:
../../src/dns-manager/nm-dns-manager.c:38:33: fatal error: libnm-util/nm-utils.h: No such file or directory
Fixes regression introduced by commit 7580cfef20.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use nm_utils_inet4_ntop() and nm_utils_inet6_ntop() instead.
And get rid of the unneeded error-checking.
gcc warns:
make[4]: Entering directory `/data/src/NetworkManager/src'
CC nm-dns-manager.lo
dns-manager/nm-dns-manager.c: In function 'merge_one_ip4_config':
dns-manager/nm-dns-manager.c:137:37: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET, &addr, buf, INET_ADDRSTRLEN) > 0)
^
dns-manager/nm-dns-manager.c:168:37: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET, &addr, buf, INET_ADDRSTRLEN) > 0)
^
dns-manager/nm-dns-manager.c: In function 'merge_one_ip6_config':
dns-manager/nm-dns-manager.c:197:64: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET, &(addr->s6_addr32[3]), buf, INET_ADDRSTRLEN) > 0)
^
dns-manager/nm-dns-manager.c:200:38: warning: ordered comparison of pointer with integer zero [-Wextra]
if (inet_ntop (AF_INET6, addr, buf, INET6_ADDRSTRLEN) > 0) {
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
gcc warns:
make[5]: Entering directory `./NetworkManager/src/platform/tests'
CC platform.o
platform.c: In function ‘do_ip6_route_add’:
platform.c:696:2: error: ‘plen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return nm_platform_ip6_route_add (ifindex, NM_PLATFORM_SOURCE_USER,
^
platform.c: In function ‘do_ip6_route_delete’:
platform.c:724:2: error: ‘plen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return nm_platform_ip6_route_delete (ifindex, network, plen, metric);
^
platform.c: In function ‘do_ip4_route_delete’:
[...]
Signed-off-by: Thomas Haller <thaller@redhat.com>
clang warns:
make[5]: Entering directory `./NetworkManager/src/platform/tests'
CC test_link_fake-test-link.o
test-link.c:133:1: error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
test-link.c:191:10: error: declaration shadows a variable in the global scope [-Werror,-Wshadow]
char *stdout = NULL;
^
/usr/include/stdio.h:173:16: note: expanded from macro 'stdout'
#define stdout stdout
^
/usr/include/stdio.h:169:25: note: previous declaration is here
extern struct _IO_FILE *stdout; /* Standard output stream. */
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED would map
to NM_DEVICE_STATE_REASON_NOW_MANAGED.
clang warns:
make[6]: Entering directory `./NetworkManager/src/devices/wifi'
CC nm-device-olpc-mesh.lo
nm-device-olpc-mesh.c:193:28: error: implicit conversion from enumeration type 'enum NMVPNConnectionStateReason' to different enumeration type 'NMDeviceStateReason' [-Werror,-Wenum-conversion]
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nm-device-olpc-mesh.c:319:27: error: implicit conversion from enumeration type 'enum NMVPNConnectionStateReason' to different enumeration type 'NMDeviceStateReason' [-Werror,-Wenum-conversion]
NM_VPN_CONNECTION_STATE_REASON_USER_DISCONNECTED);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Thomas Haller <thaller@redhat.com>
g_error() does not return, but clang seems not to understand that
and gives the following warning.
make[4]: Entering directory `./NetworkManager/src'
CC NetworkManagerUtils.lo
NetworkManagerUtils.c:1584:1: error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
This bug has no real consequense, because the numerical values of the
enum values are identical.
clang warns:
make[4]: Entering directory `./NetworkManager/src'
CC nm-vpn-connection.lo
vpn-manager/nm-vpn-connection.c:179:10: error: implicit conversion from enumeration type 'VpnState' to different enumeration type 'NMVPNConnectionState' (aka 'enum NMVPNConnectionState') [-Werror,-Wenum-conversion]
return STATE_UNKNOWN;
~~~~~~ ^~~~~~~~~~~~~
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since kernel commit 8fe02e167efa8ed4a4503a5eedc0f49fcb7e3eb9,
the value NL80211_FREQUENCY_ATTR_NO_IR replaces PASSIVE_SCAN
and NO_IBSS. Hence their numerical values are identical and
cause the following compiler warning.
clang warns:
make[4]: Entering directory `./NetworkManager/src'
CC wifi-utils-nl80211.lo
platform/wifi/wifi-utils-nl80211.c:683:48: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
[NL80211_FREQUENCY_ATTR_NO_IBSS] = { .type = NLA_FLAG },
^~~~~~~~
platform/wifi/wifi-utils-nl80211.c:682:53: note: previous initialization is here
[NL80211_FREQUENCY_ATTR_PASSIVE_SCAN] = { .type = NLA_FLAG },
^~~~~~~~
Signed-off-by: Thomas Haller <thaller@redhat.com>
The variable is not actually unused, because it is used
to free the nl_object instance.
clang warns:
make[4]: Entering directory `./NetworkManager/src'
CC nm-linux-platform.lo
platform/nm-linux-platform.c:1746:35: error: unused variable 'obj_cleanup' [-Werror,-Wunused-variable]
auto_nl_object struct nl_object *obj_cleanup = obj;
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Due to a bug, when dcb fails it would change the device state
to NM_DEVICE_STATE_UNKNOWN (zero), instead of NM_DEVICE_STATE_FAILED.
clang warns:
make[4]: Entering directory `./NetworkManager/src'
CC nm-device-ethernet.lo
devices/nm-device-ethernet.c:1237:30: error: implicit conversion from enumeration type 'enum NMActStageReturn' to different enumeration type 'NMDeviceState' [-Werror,-Wenum-conversion]
NM_ACT_STAGE_RETURN_FAILURE,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
devices/nm-device-ethernet.c:1261:30: error: implicit conversion from enumeration type 'enum NMActStageReturn' to different enumeration type 'NMDeviceState' [-Werror,-Wenum-conversion]
NM_ACT_STAGE_RETURN_FAILURE,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Thomas Haller <thaller@redhat.com>
When building with '--disable-concheck' with libsoup installed,
configure would set HAVE_LIBSOUP. But without connection
checking, we didn't link against libsoup, resulting in a
linker error.
Add a new configure option '--with-libsoup' / '--without-libsoup'
to control whether linking against libsoup.
The combination '--without-libsoup --enable-concheck' does not
make sense.
https://bugzilla.gnome.org/show_bug.cgi?id=734062
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.
In nm_ip4_config_commit() and nm_ip6_config_commit() there is no need
to copy the route. Just use the pointer returned from nm_ip4_config_get_route()/
nm_ip6_config_get_route().
Signed-off-by: Thomas Haller <thaller@redhat.com>
At some places, we considered a default route to be a route with
destination network 0.0.0.0 (::). This is wrong because a default route
is a route with plen==0.
This is for example relevant for OpenVPN which adds two routes
0.0.0.0/1 and 128.0.0.0/1 to hijack the default route. We should
not treat 0.0.0.0/1 as default route, instead NM should treat
it as any other subnet route (even if it effectively routes large
parts).
Signed-off-by: Thomas Haller <thaller@redhat.com>
The next-hop should always be set to route->gateway. Just as
it is done in the IPv4 case too.
This bug only affected routes to '::/p via gateway', with a
non-zero gateway and p > 0. That is a quite uncommon case, because
usually non-default routes have not a net-part all zero.
Signed-off-by: Thomas Haller <thaller@redhat.com>
gcc warns:
make[4]: Entering directory `/data/src/NetworkManager/src'
CC nm-device.lo
In file included from devices/nm-device.c:73:0:
../src/config/nm-config.h:61:13: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
const guint nm_config_get_connectivity_interval (NMConfig *config);
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
When SELinux is disabled, getfscreatecon() fails leaving se_ctx_prev undefined
and then later freecon (se_ctx_prev) fails with a crash. Initializing
se_ctx_prev to NULL fixes the crash. (It is fine to pass NULL context to
setfscreatecon()).
Testcase:
1) Enable ifcfg-rh plugin in /etc/NetworkManger/NetworkManger.conf
plugins=ifcfg-rh
2) Edit /etc/sysconfig/selinux to contain
SELINUX=disabled
3) Reboot
4) Set hostname via nmcli, nmtui or D-Bus SaveHostname() call
5) NM crashes
https://bugzilla.redhat.com/show_bug.cgi?id=1122826
If no APN is specified, passing "" to ModemManager indicates that
the connection should use the default subscription APN, which the
modem and the network determine themselves. This doesn't work
with all modems and operators, but in that case the user can
specify the APN.
In commit 215306f5 [1], NetworkManager was changed to require an APN for GSM
connections; previously, an omitted APN was taken as "use the default APN
for this device".
ModemManager supports this behaviour with an empty APN string; older
NetworkManager versions support this behaviour with no APN in the
settings. Choose the older NM behaviour, for backwards compatibility.
[1] commit 215306f5a1
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Jan 10 23:39:12 2011 -0600
core: add AddAndActivate D-Bus method
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=729665
With WWAN, the DHCP is all done in modem firmware, and never started
until we know we have a successful packet connection to the network.
Which means the modem firmware already knows the IP details and
is ready to provide them. Furthermore, since the DHCP is done on
what is essentially a reliable, wired point-to-point link, we don't
have to waste time with retransmits for dropped packets either.
OtherConf implies the address has already been delivered via RA,
and possibly DNS too, meaning our IP configuration is already
good enough. If nothing on the network bothers to reply to our
DHCPv6 Information Requests, let's just run with the config
we already have instead of tearing down the whole device.
Avoid this error:
NetworkManager[25181]: <warn> (cdc-wdm1): Failed to connect 'T-Mobile Internet': Connection requested IPv4 but IPv4 is unsuported by the modem.
NetworkManager[25181]: <info> (cdc-wdm1): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]
** (NetworkManager:25181): CRITICAL **: mm_modem_simple_disconnect: assertion 'MM_IS_MODEM_SIMPLE (self)' failed
self->priv->simple_iface is only valid if stage1/prepare actually
completes, so don't try to access it if stage1/prepare failed.
Child devices shouldn't be exposed as real NMDevices (yet) since the
configuration and life cycle is controlled by the parent. We already
do this if the ip_iface is known when the child device is added, but
PPP and other transient interfaces often show up just before we know
the parent's ip_iface.
Add an 'unknown' value; make the type an enum, and rename it since
this enum is private to NetworkManager and abstracts differences
in old and new MM.
We also need separate methods for IPv4 and IPv6 since they may not
use the same mechanism. For example, IPv4 may use DHCP but IPv6 may
require static configuration, based on what the modem firmware wants.
Add support for IPv6 to the pppd plugin and return the interface identifiers
to NetworkManager. Use those to construct the IPv6LL addresses for the
PPP interface and the peer.
We want to set the WWAN config last, to ensure that the configuration we
use overwrites anything that pppd might have set, becuase it touches some
stuff itself. That means we have to keep the WWAN config separate, since
dev_ip4_config is used for DHCP and IPv4LL, which we always set first to
ensure they these don't overwrite external, administrator added config
(eg, priv->ext_ip4_config).
This also synchronizes the IPv4 config path with the upcoming IPv6
config path.
If the IID cannot be generated, the IPv6 address resulting from
the combination of an advertised prefix and 64-bits of zero is
both wrong and quite likely to clash with some other machine on
the network that doesn't implement IPv6 quite right either.
Require an valid interface identifier. If NetworkManager doesn't
know how to generate one, then we should fix NM to do so.
Ethernet-like interfaces aren't the only type of interfaces that can
run IPv6 but the rdisc code only returns an address if the interface's
hardware address is 6 bytes.
Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own
specifications for constructing IPv6 addresses and we should honor
those.
So instead of expecting a MAC address, let each device subclass
generate an Interface Identifier and use that for rdisc instead.
We no longer need a class method for reading the hardware address
length, for a couple reasons:
1) Using the IP interface hardware address for IP operations now makes
NMDevice's priv->hw_addr_len constant. So there's no reason to re-read
it all the time.
2) get_hw_address_length() is now only used for determining whether the
hardware address is permanent, and that only mattered for Bluetooth.
Since Bluetooth interfaces have a bogus interface name, they will never
have a valid ifindex, and thus nm_platform_link_get_address() would be
useless. So instead of using the 'permanent' stuff, just don't bother
updating the hardware address if the NMDevice's ifindex isn't valid,
and let subclasses pass the initial hardware address at device creation.
This also works correctly for NMDevice classes that previously
implemented get_hw_address_length() like ADSL and WWAN, since those
too will never have a valid ifindex or a valid hardware address.
3) Reading the device's hardware address length just ended up calling
nm_platform_link_get_address() for most devices anyway, so
nm_device_update_hw_address() would effectively read the link address
twice (once to read the length, the second time to read the actual
address). Let's just read the address once.
