config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Add nm-core-types.h, typedefing all of the GObject types in
libnm-core; this is needed so that nm-setting.h can reference
NMConnection in addition to nm-connection.h referencing NMSetting.
Removing the cross-includes from the various headers causes lots of
fallout elsewhere. (In particular, nm-utils.h used to include
nm-connection.h, which included every setting header, so any file that
included nm-utils.h automatically got most of the rest of libnm-core
without needing to pay attention to specifics.) Fix this up by
including nm-core-internal.h from those files that are now missing
includes.
Most NMDevice types defined their own error domain but then never used
it. A few did use their errors, but some of those errors are redundant
with NMDeviceError, and others can be added to it.
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
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.)
Make all mac-address properties (including NMSettingBluetooth:bdaddr,
NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be
strings, using _nm_setting_class_transform_property() to handle
translating to/from binary form when dealing with D-Bus.
Update everything accordingly for the change, and also add a test for
transformed setting properties to test-general.
NMDeviceBond, NMDeviceBridge, and NMDeviceTeam all used basically the
same code to generate a default interface name. Move it into
nm_utils_complete_generic().
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>
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).
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).
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>
Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
Makes the function working for link destinations longer then 127 bytes and
fixes a potential bug that the result of readlink() was not zero
terminated for long paths.
Probably this would be no problem, but better be save.
Related: https://bugzilla.redhat.com/attachment.cgi?id=885371
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.
Attempting an immediate reconnect if the peer terminates the connection
sometimes results in the peer not being ready to negotiate a new
connection, while a short delay allows the peer to correctly tear
down the old connection and get listen for a new one. Introduce
a short delay when activating a PPPoE connection if a PPPoE
connection was recently deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1023503https://bugzilla.redhat.com/show_bug.cgi?id=602265
Rebased to master by jklimes.
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
These turn out to be pretty useless, since their functions are already
covered by each device's state-changed handler or can be done in other
places like deactivate().
https://bugzilla.gnome.org/show_bug.cgi?id=702190
Rather than passing UDI, ifname, and driver name to the device
constructors as separate arguments, just pass the NMPlatformLink
instead and let it parse them out.
Virtual types still take UDI and ifname separately, since we create
fake NMDevices for them for autoactivating connections. That's weird
in other ways too though, so perhaps this should be revisted.
Some devices aren't expected to support carrier detection, so there's
no reason to have NMDevice log about it. Move that message into
NMDeviceEthernet, where failure to support carrier-detect really is
worth mentioning.
Also, make NMDeviceEthernet use NMPlatform for carrier-detection
detection (and move the MII carrier-detect-support check from
NMDeviceEthernet into NMLinuxPlatform).
Finally, have NMDeviceGeneric actually check whether the device
supports carrier detect, rather than just always assuming it doesn't.
This is really, really old 2007-era code. Any NMDevice that gets
created is already supported, so there's no reason to have every
device set NM_DEVICE_CAP_NM_SUPPORTED. For those subclasses that
only set that capability, we can remove the subclass method
entirely. Next, it turns out that the "type capabilities" code
wasn't used anywhere, so remove that too. Lastly, "cipsec"
interfaces haven't been used on linux in about 5 years (they
were created by the Cisco binary-only IPSec kernel module for
Cisco VPNs long before vpnc and openswan came around) so we can
remove that code too.
With carrier handling moved to NMDevice, the only thing left in
NMDeviceWired was speed, which was actually ethernet-specific anyway.
So move that to NMDeviceEthernet, and then kill NMDeviceWired.
Change the way that nm-properties-changed-signal works, and parse the
dbus-binding-tool-generated info to get the exact list of properties
that it's expected to export.
This makes NM_PROPERTY_PARAM_NO_EXPORT unnecessary, and also fixes the
problem of properties like NMDevice:hw-address being exported on
classes where it shouldn't be.
