When determining the system hostname, /etc/hostname should override
/etc/sysconfig/network, so monitor both files.
When setting the hostname, set it in /etc/hostname, and delete the
/etc/sysconfig/network HOSTNAME entry if present.
https://bugzilla.redhat.com/show_bug.cgi?id=831735
When updating connections, it is less confusing to reuse the existing file
instead of renaming files according to connection's ID. That reduces surprises
of moving connection files when a connection is edited.
By specifying GLIB_VERSION_MAX_ALLOWED=GLIB_2_34, we tell GLib not to
warn us about e.g. g_type_init() being deprecated in 2.36.
This avoids the NM build blowing up with the default -Werror
configuration if we happen to have a newer GLib in the buildroot.
We had separate checks for glib-2.0, gobject-2.0, gmodule-2.0, and
gio-unix-2.0. It doesn't make sense to link a binary against all 4
because gio-unix-2.0 depends on glib-2.0 and gobject-2.0. Doing this
actually breaks things in unusual circumstances.
Generally, few bits of NM actually just use glib, and not gio. We
might as well coalesce those requirements together, even if it means
in some cases we "overlink". Additionally, I chose for now to fold
gmodule-2.0 in as well, even though many fewer programs need it. The
cost of overlinking is quite small.
The benefit of this is less repeated junk in Makefile.am, as well as
more centralized control over GLib. A followup patch will allow us to
set -DGLIB_VERSION_MIN_REQUIRED in just one place, rather than having
to replicate it 4 times.
The NM configure is still suboptimal - for example, libpolkit-1
depends on gio-2.0, so really we should determine the compiler flags
all in one pass. But it doesn't matter too much for now.
This functionality is (mostly) obsoleted by the newer
GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED defines. With
this, your build doesn't all of a sudden blow up if we deprecate
something in GLib - you have to explicitly opt-in to the newer
version.
G_DISABLE_DEPRECATED does still apply for macros and things that can't
take __attribute__((deprecated)), but it's not really worth the pain
and cargo culting around just for that.
The logic behind the `iface' property (which actually is removed) gets split
into three new properties, as follows::
* `uid': Just defines a new string property which must contain a unique ID of
the modem, mainly for logging.
* `control-port': a string property defining which is the control port the
modem uses. This property is actually optional and may be specified as NULL.
The main purpose of this property is to allow the easy integration of the
new ModemManager into the `NMDeviceBt' object. The bluetooth device needs
to know the port used by the modem; and we cannot use the Data port
information as that is only available until the bearer is created. Instead,
for the new ModemManager we will use the control port information exposed.
* `data-port': a string property defining which is the data port to use in the
connection. This property is always defined in the `NMModemGsm' and
`NMModemCdma' objects.
We don't want to depend in the `NMModem' interface on an enumeration which is
very specific to the old ModemManager interface, so we'll just skip exposing it
and instead we'll just give a new boolean property which tells whether the modem
is connected or not (which was at the end the whole purpose of the `state'
property).
This property is not really used anywhere; so pointless to have it around.
Also, we already make sure in `NMModemManager' that the so called 'master'
device is valid and exists.
The `NMModem' object is split into two objects now:
* The new `NMModemGeneric' object contains all the implementation specific to
the old ModemManager interface.
* The `NMModem' object keeps all the generic stuff; e.g. it doesn't even depend
on dbus-glib for anything. Several properties in `NMModem' are also now set
as non-construct-only, as we know that the new ModemManager only knows some
of the stuff once a bearer has been created, not once a modem is available.
See src/modem-manager/README for more information.
Distribution-specific builds are now handled by feature and not by
distro. This allows you to fine-tune the options to your liking and
also allowed us to reduce the number of specific values.
The default values of these options are still derived from *-version
and *-release files in /etc.
The following five distribution-specific features are now available
(and default on distributions in parenthesis):
--enable-ifcfg-rh (Fedora, RHEL and Mandriva)
--enable-ifcfg-suse (SUSE)
--enable-ifupdown (Debian and Ubuntu)
--enable-ifnet (Gentoo)
--with-netconfig (SUSE)
Since --with-distro is now removed, there is nothing to prevent generic
builds. If you build on an unknown distribution, all of the features
above will be disabled by default.
It doesn't make much sense to install initscripts in current distributions. Most
of them either don't use initscripts at all, locally patch the initscripts or
supply their own. This allows us to eventually drop the --with-distro configure
option.
Many current distributions support multiple init systems and it doesn't make
sense for upstream to make the choice for them. Distributors can still make
their scripts copy one of the initscripts from the source tree if they wish so.
NetworkManager can use resolvconf and netconfig as alternatives
to direct modifications to /etc/resolv.conf. You can now choose
whether to build with netconfig or not.
The default is --with-netconfig=yes on SUSE and --with-netconfig=no
on other distributions. Default --with-resolvconf=no still applies
on any distribution.
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
If the mesh device gets removed first, ensure it cleans up its
signal handlers so they don't get called when the wifi device
is removed. Fixes warnings on NM shutdown where the mesh device
object could be used after being freed.
Some configurations won't have a gateway address, because they
are point-to-point (/32). The previous code expected one and
asserted if a gateway was not found; but even without the
assertion, other code expected a non-NULL gateway. Handle that
by defaulting the gateway to 0.0.0.0 (IPv4) or :: (IPv6) and
override that with a better gateway if we have one, otherwise
just use 0.0.0.0/:: since we already know the IP config we're
settings should be the default one.
Add a helper like nm_utils_security_valid() except for access point
mode. We can't use nm_utils_security_valid() without changing the
arguments, hence the new function. Plus in AP mode all you care about
are the device capabilities, not AP flags since the device *is*
the AP.
With both WEXT and nl80211; this wasn't an issue before because
devices can still scan in adhoc mode. But we do need to ensure
that the device is in Infrastructure mode when we deactivate a
Hotspot.
Since the frequency and/or BSSID may not be known immediately, it's
nice to update the export AP object when we do know them, so you
don't end up with missing information like:
SSID BSSID MODE FREQ
'testap' 00:00:00:00:00:00 AP 0 MHz
Note that the "rate" is never updated, because in AP-mode the bitrate
is actually different for each client, so no single rate makes sense.
Scanning doesn't work well in AP mode, because then you're off-channel
and not serving your clients, which isn't good for anyone. Plus,
nl80211 refuses to scan in AP mode anyway, so just don't scan.
Second, track the device's mode based on the connection we're activating
or have activated, not based on whatever mode the kernel drivers are
using that second. That is more consistent, since there's a race between
when the connection starts being activated, when the device will be in
INFRA mode, and when the supplicant actually gets around to changing the
mode.
Third, fix various other codepaths that weren't quite expecting AP mode.
And return an error when trying to activate an AP mode connection
if the supplicant does not support it.
With wpa_supplicant 1.0 and earlier there is no way to positively detect
whether AP mode is supported, so we simply try to start AP mode
and then fail if it doesn't work.
With more recent versions we can check the Introspection data
(if the supplicant has been built with introspection enabled) or
check the global Capabilities (if the supplicant is recent enough)
for positive indication of AP mode support.
A new value for NM80211Mode is introduced (NM_802_11_MODE_AP) and the
new mode is passed to wpa_supplicant analogous to adhoc-mode.
The places which need to know the interface mode have been extended to
handle the new mode.
If the configuration does not contain a fixed frequency, a channel is
selected the same way as with adhoc-mode before.
