We were linking libndp into the NetworkManager binary, but it ought to
be marked as a dependency of libNetworkManager, in case a test
exercises that code.
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
Several plugins were using -I$(top_srcdir)/libnm-glib, which is bad
since libnm-glib has its own nm-types.h which is different from src's.
Worse yet, some were actually linking against libnm-glib (which
presumably only worked at all because they weren't calling any
functions in it and so the linker just ignored the request). Fix both
problems.
5b4be27f moved test-dhcp-options from src/tests/ to
src/dhcp-manager/tests/, but src/tests/Makefile.am still included it
in "TESTS" (which would still work until you tried to build from a
clean tree...)
The goal is to remove generic logic from nm_dhcp_client_new_options(),
since library-ized DHCP clients won't ever call that function since
their native data format isn't a hash table of strings.
The options hash is never used except for BOUND events, so don't
bother caching it in the DHCP client object. Just pass it along
with the BOUND state change, like the IP configuration object.
Previously the tests required that a NMDHCPClient object was
created, but all that's really being tested is the DHCP option
parsing and that doesn't need a client object now that the
option parsing has been split out.
Also, the options test wasn't in src/dhcp-manager/, so put it there.
Lastly, the test ran for both dhclient and dhcpcd, but the code
executed for both cases was the same, so there's no reason to keep
running the test for both clients.
More robust against ifname changes, plus we save some strcmps().
For the most part, the interface name should be informational
only and unused for actual control logic.
Instead of using a separate signal for it, just drop and release
the client object when it reaches terminate states like TIMEOUT,
FAIL, and DONE. The 5 second removal signal timeout appears to
no longer be necessary, since the running child process is killed
synchronously.
Modify code so that listeners remove state change signal handlers
before stopping the client. Which means we can remove the 'emit_state'
argument from nm_dhcp_client_set_state().
DHCP failure should just clean up the client in all cases. This
also has the benefit of removing the signal handler for the DHCP
client's state-change signal before telling the client to terminate,
which will simplify some DHCP code later.
No reason to have two signals for the same thing. Previously, the
TIMEOUT signal was used for the internal overall DHCP transaction
bound, while DHCP_STATE_TIMEOUT/DHC_TIMEOUT was a signal from
the DHCP client itself that something had timed out. But in both
cases the results should be the same, so just collapse the
stand-alone TIMEOUT signal into the DHCP_STATE_TIMEOUT state.
The existing DHC_* states are pretty specific to dhclient, and aren't
useful for more generalized DHCP. NetworkManager wasn't using many
of the states anyway, and doesn't need to differentiate between
states like REBOOT/REBIND/RENEW anyway. So simplify the DHCP states
into the ones we really care about.
'address' was not initialized, so using address.ifindex was not
going to work.
==6777== Conditional jump or move depends on uninitialised value(s)
==6777== at 0x44A6DB: check_cache_items (nm-linux-platform.c:1510)
==6777== by 0x44AA4F: announce_object (nm-linux-platform.c:1586)
==6777== by 0x44A59A: refresh_object (nm-linux-platform.c:1666)
==6777== by 0x44A676: check_cache_items (nm-linux-platform.c:1517)
==6777== by 0x44A812: announce_object (nm-linux-platform.c:1566)
==6777== by 0x44D957: handle_udev_event (nm-linux-platform.c:3964)
==6777== by 0x3BAFC125A7: g_closure_invoke (gclosure.c:777)
==6777== by 0x3BAFC2465C: signal_emit_unlocked_R (gsignal.c:3586)
==6777== by 0x3BAFC2C3E1: g_signal_emit_valist (gsignal.c:3330)
==6777== by 0x3BAFC2C69E: g_signal_emit (gsignal.c:3386)
==6777== by 0x3D93A03BE3: ??? (in /usr/lib64/libgudev-1.0.so.0.1.3)
==6777== by 0x3BAF8521D5: g_main_context_dispatch (gmain.c:3066)
Always requesting this appears to cause some devices to ignore
DHCP requests, like the ZTE 823D, ZTEMF93E, Alcatel W800Z.
dhclient probably knows better than NM when to request the
server's ID, so leave that up to dhclient. We don't do anything
interesting with it anyway.
nm-version.h was getting disted, making srcdir!=builddir work for
tarball builds, but not for git builds.
Also, remove "-I${top_builddir}/include" from all Makefile.ams, since
there's nothing generated in include/ any more.
NetworkManager.h, NetworkManagerVPN.h, and nm-version.h are part of
the libnm-util API, so move them to libnm-util.
include/ still contains headers that are strictly NM-internal (eg,
nm-glib-compat.h).
Even if administrator-configured hostname (/etc/hostname) takes precedence
over other hostname configurations, we don't take "localhost", "localhost6",
"localhost.localdomain", "localhost6.localdomain6" as such. These values might
be set by some tools (like installer). But that's not right and we compensate
for that. It doesn't make much sense that an admimistrator would set these
values manually (intentionally), because leaving /etc/hostname empty will
result in "localhost" hostname anyway (set by systemd).
https://bugzilla.redhat.com/show_bug.cgi?id=1110436
The kernel adds these for various operations; they are short-lived,
added often, and not useful to NetworkManager. Ignore them. This
prevents NetworkManager from continuously updating the IPv6 config
and emitting state changes to clients via D-Bus for useless changes.
Quite possibly these logging lines hit before we setup nm-logging
initially and before NM main() calls nm_logging_syslog_openlog().
This is because NM first needs to read the configuration, before setting
up logging.
Note however, that nm-logging is robust against both.
If nm_logging_setup() was not yet called, it will automatically setup
"DEFAULT","INFO".
If nm_logging_syslog_openlog() was not yet called, it will redirect
logging to g_log() -- which basically ends up at g_warning() again.
Still this is useful in case when hitting those lines *afterwards*.
Especially, later when we support reloading of configuration.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The interface is owned by the parent NMDeviceBt and is not independently
usable. If not ignored, NM tries to assume a connection on the bnep
interface and messes the Bluetooth connection up.
The addition of Bluez5 support mistakenly broke support for Bluez4 property
change events. Bluez4 uses a custom D-Bus interface that we must explicitly
handle.
This caused NM to ignore BT devices immediately after pairing, since the UUIDs
only show up through a custom Bluez4 PropertyChanged even when pairing is
complete. Only then do we finally know priv->capabilities, and only then is
the NMBluezDevice usable.
