generate-plugin-docs.pl was assuming that it was being run out of
srcdir, and so failed in srcdir!=builddir builds (such as "make
distcheck"). Fix that.
Also, update .gitignore
In the specific case that triggered this bug, both eth0 and eth0.123
existed and were configured before NM started, and a valid saved connection
existed for eth0.123. eth0 was ordered before eth0.123 in the Platform's
link list. When the end of add_devices() was reached for eth0 and
system_create_virtual_devices() was called, NM created an NMDevice for
the pre-existing eth0.123 link due to the saved connection, and
ignored the existing configuration because system_create_virtual_device()
re-calls add_device() with generate_con = FALSE.
Instead, we should allow system_create_virtual_device() to call add_device()
with generate_con = TRUE if the interface existed before NM created it. We
only want to skip connection assumption if the device was actually just
created by NM, in which case it cannot have any configuration to assume.
This didn't previously matter because BT/WWAN/WiFi/ADSL can't easily
assume existing connections due to the external helpers involved, but
when we converted Team support to a plugin we now want to allow this.
Instead of handling iBFT (iSCSI Boot Firmware Table) in the ifcfg-rh plugin,
create a new plugin for it. This allows all distributions to use iBFT
configuration, and makes both iBFT handling and ifcfg-rh less complicated.
The plugin (like the old ifcfg-rh code) creates read-only connections backed
by the data exported by iscsiadm. The plugin does not support adding new
connections or modifying existing connections (since the iBFT data is
read-only anyway). Instead, users should change their iBFT data through
the normal firmware interfaces.
Unmanaged devices can be configured through NetworkManager.conf and the
normal 'keyfile' mechanisms.
(In the future, we'll read this data directly from the kernel's
/sys/firmware/ibft/ethernetX directory instead of iscsiadm, since the
kernel has all the information we need and that's where iscsiadm gets
it from anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=734009
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
The module is used for building man pages by generate-plugin-docs.pl script.
1c2174a libnm-util: generate-plugin-docs.pl script for extracting plugin docs
man/nm-settings-keyfile.xml is generated via an XSLT stylesheet applied to
libnm-util/nm-keyfile-docs.xml. Then a manual page is generated from the XML.
The scripts extracts plugin description from document comments for particular
properties and builds a XML file out of the data. The XML file can be used
later for generating manual pages or other documentation.
Unfortunately, gtk-doc won't allow descriptions that would be separated from
the main gtk-doc stuff. But it is still useful to have plugin description bits
co-located with property definitions. We use our home-grown comments and parse
them ourself. Afterall it's not that bad, and in addition it brings us a
freedom in shaping the comments to our needs.
by disconnecting signal handlers in dispose().
Commit 6a19e68a moved nm_connection_clear_secrets() from plugins' finalize() to
NMSettingsConnection's dispose(). But clearing secrets emits "changed" signal
which cause changed_cb() to be called and emit_updated() scheduled. And
emit_updated() was called later after finalize() on released object.
The crash can be invoked by having two keyfile connection files with the same
uuid in them.
Backtrace:
(NetworkManager:12262): GLib-GObject-WARNING **: attempt to retrieve private data for invalid type 'NMSettingsConnection'
Program received signal SIGSEGV, Segmentation fault.
emit_updated (self=0xf38dd0 [NMSettingConnection]) at settings/nm-settings-connection.c:401
401 NM_SETTINGS_CONNECTION_GET_PRIVATE (self)->updated_idle_id = 0;
(gdb) bt
#0 emit_updated (self=0xf38dd0 [NMSettingConnection]) at settings/nm-settings-connection.c:401
#1 0x0000003c49647825 in g_main_dispatch (context=0x785970) at gmain.c:2539
#2 g_main_context_dispatch (context=context@entry=0x785970) at gmain.c:3075
#3 0x0000003c49647b58 in g_main_context_iterate (context=0x785970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3146
#4 0x0000003c49647f52 in g_main_loop_run (loop=0x7857c0) at gmain.c:3340
#5 0x000000000042d4e9 in main (argc=1, argv=0x7fffffffe508) at main.c:679
When you first click "Add" in an address list, it adds a new field,
and the "Add" button becomes insensitive (because the new field is
empty, and thus not valid). But if you then clicked "Remove", "Add"
stayed insensitive. Fix that.
When switching to and fro old branches, you end up with
the (now removed) libgsystem submodule. As `git clean -fd`
refuses to remove git-repositories, this is especially annoying.
Tell git to ignore it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This wpa_supplicant option is not named "private_key_passwd2". Looks
like this regressed in e5ed391f28.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Previously, user could only change the udev base directory,
but not disabling installation entirely.
Support this now with:
./configure --with-udev-dir=no
or
./configure --without-udev-dir
Also, just passing '--with-udev-dir' equals '--with-udev-dir=yes'.
Treat 'yes' equal to the default '/lib/udev'.
Also, check that the path is an absolute path starting with a '/'.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous implementaiton of the compatibility wrapper failed
with clang when used inside a macro. This seems like a compiler
error not to ignore the deprecation. Workaround by refactoring
the g_type_ensure() wrapper.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
nm_remote_settings_list_connections() ensures the connections are loaded first.
We check "help" commands before getting connections, because it is time
intensive action.
When removing/replacing a NMSetting in an NMConnection, we have
to disconnect setting_changed_cb() from the "notify" signal.
Backport commit dfba4ce1e1 from
libnm-core.
Signed-off-by: Thomas Haller <thaller@redhat.com>
verify() used to modify interface-name of the base settings. This is
discouraged, because verify() should not touch the connection.
For libnm-core we can change behavior and only modify the connection
in normalize().
Also, be more strict not to verify() sucessfully on invalid
interface-name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When calling nm_setting_verify() without providing any settings in @all_settings,
we assume that the setting on its own might be valid.
Only when checked together with all settings, we want to consider the setting
in the full context. nm_connection_verify() ensures to pass on a list of settings.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previously, NMSettingInfiniband:verify() silently modifies the
setting for invalid MTU. verify() should not do that.
For libnm-core we can change behavior and implement normalization
of MTU. This changes behavior for NMSettingInfiniband:verify() so
that MTU gets no longer fixed by verify() alone. Instead verify()
fails with a verification error.
Due the possibility to normalize the MTU, NM still can receive
invalid settings and fix it.
For libnm-core we don't change behavior, merely add a code comment.
Signed-off-by: Thomas Haller <thaller@redhat.com>
We would expect that attempts to normalize a connection
are successful as verify() indicates. This way, a connection
is not modified if it cannot be fixed, and a connection will
be valid and modified after attempts to normalization.
However, there might be subtle, unexpected ways how this can fail.
For example, if NMSettingConnection:verify() detects a missing base type
setting, it returns NORMALIZABLE_ERROR if it finds a valid
NMSettingConnection:type. Normalization then adds an empty, default
setting. However, a new verify() might fail due to other reasons.
This would be a bug in NMSettingConnection:verify() which must not
indicate that it is able to normalize the connection, when it actually
is unable to do so.
Such bugs need fixing, but the code should be more robust to this case
because there might be complex, unanticipated situations.
Especially since NM relies on having a valid connection after normalize(),
so a strict error-out behavior is important.
Signed-off-by: Thomas Haller <thaller@redhat.com>
