Even if we never receive an RA, if there are manually-specified or external
addresses, consider IPv6 to complete successfully. No reason to fail IPv6
if we have IP configuration already, but RA doesn't respond. If RA shows
up again, we're still listening for it and will apply the config at that
time.
Reporter left SLAAC enabled (because it's default and requires being
explicitly turned off) and added manual IPv6 address. They expected that
address to be assigned very soon after starting the connection, but it was
not assigned.
This happened because NM waits for RA before assigning any IPv6 configuration,
including the manually specified addresses. In the reporters case, there was
no IPv6 router on the network, so NM waited indefinitely for a router
advertisement and never applied any IPv6 configuration.
It seems reasonable to apply any IPv6 configuration we have available, when
we have it. We already apply RA configuration before starting DHCP, and
apply DHCP configuration if/when we get that.
The IPv4 pre-commit hook was called right before the config was
committed, while the IPv6 one was called before commit in only
one case (from nm_device_activate_ip6_config_commit). The IPv4
behavior is the intended behavior.
Note that this doesn't have any actual effect yet, since nothing
actually implements the IPv6 pre-commit hook
For NMDeviceWifi and NMDeviceWimax, the printf format string for
nm_utils_complete_generic() was created based on ssid/nsp. Since
these input strings are untrusted, this is a serious bug.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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.
For devices where we don't set the hardware address at construct time,
the first call to nm_device_update_hw_address() was hitting a
return-if-fail.
Also, when updating the hardware address, we were leaking the old
value.
Now that we have nm_utils_hwaddr_matches() for comparing addresses
(even when one is a string and the other binary), there are now places
where it's more convenient to store hardware addresses as strings
rather than binary, since we want them in string form for most
non-comparison purposes. So update for that.
In particular, this also changes nm_device_get_hw_address() to return
a string.
Also, simplify the update_permanent_hw_address() implementations by
assuming that they will only be called once. (Since they will.)
Add nm_utils_hwaddr_matches(), for comparing hardware addresses for
equality, allowing either binary or ASCII hardware addresses to be
passed, and handling the special rules for InfiniBand hardware
addresses automatically. Update code to use it.
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.
Lots of old code used struct ether_addr to store hardware addresses,
and ether_aton() to parse them, but more recent code generally uses
guint8 arrays, and the nm_utils_hwaddr_* methods, to be able to share
code between ETH_ALEN and INFINIBAND_ALEN cases. So update the old
code to match the new. (In many places, this ends up getting rid of
casts between struct ether_addr and guint8* anyway.)
(Also, in some places, variables were switched from struct ether_addr
to guint8[] a while back, but some code still used "&" when referring
to them even though that's unnecessary now. Clean that up.)
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.)
"NetworkManager.h"'s name (and non-standard capitalization) suggest
that it's some sort of high-level super-important header, but it's
really just low-level D-Bus stuff. Rename it to "nm-dbus-interface.h"
and likewise "NetworkManagerVPN.h" to "nm-vpn-dbus-interface.h"
For some reason, the flags used by o.fd.NM.SecretAgent.GetSecrets were
defined as both NMSecretAgentGetSecretsFlags in
libnm{,-glib}/nm-secret-agent.h, and then separately as
NMSettingsGetSecretsFlags in include/nm-settings-flags.h.
(NMSettingsGetSecretsFlags also had an additional internal-use-only
value, but that was added later after the duplication already
existed.)
Fix this by moving NMSecretAgentGetSecretsFlags from libnm to
nm-dbus-interface.h, adding the internal-use-only value to it as well,
updating the core code to use that, and then removing
nm-settings-flags.h.
GLib/Gtk have mostly settled on the convention that two-letter
acronyms in type names remain all-caps (eg, "IO"), but longer acronyms
become initial-caps-only (eg, "Tcp").
NM was inconsistent, with most long acronyms using initial caps only
(Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP,
PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all
three-or-more-letter-long acronyms (and update nmcli and nmtui for the
libnm changes).
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.
Make use of the previously added _LOG() macros in nm-device.c.
This reduces code, but also ensures printing the same prefix for
every logline produced *for* a device instance.
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>
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>
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.
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.
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.
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.
