NMConfigDevice was added because in the 0.9.8 days, when each subdir
of src/ was compiled separately, it was impossible to make src/config/
depend on src/devices/ because of circular dependencies.
Since now everything gets compiled into a single libNetworkManager.la,
this is no longer a problem, and so NMConfigDevice is just an
unnecessary complication.
NMConfig accepted no-auto-default and ignore-carrier lists with
untagged specs (ie, interface names not prefixed with
"interface-name:" and hardware addresses not prefixed with "mac:").
Move that handling into nm_match_spec_interface_name() and
nm_match_spec_hwaddr() instead.
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...)
In preparation for library-based DHCP clients, remove some assupmtions
that all DHCP clients are subprocesses, and that all DHCP options
get passed back NM via D-Bus.
https://bugzilla.gnome.org/show_bug.cgi?id=732965
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)
test-remote-setting-client uses a macro:
#define test_assert(condition) \
do { \
if (!G_LIKELY (condition)) \
cleanup (); \
g_assert (condition); \
} while (0)
where cleanup() kills the fake remote-settings service and unrefs
settings. However, in many cases, "condition" would involve a test
against a connection that was owned by settings, so if the check
failed, the connection would end up getting freed by cleanup(), and so
then the second invocation of condition would result in the program
aborting on a failed check somewhere else (eg, "invalid unclassed
pointer in cast to 'NMConnection'") rather than displaying the failed
assertion that had gotten us to that point.
Fix this by not unreffing settings from cleanup(); in the normal exit
case we can just have main() unref it, and in the assertion-failed
case, we don't need to free things anyway.
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.
In locales where the Wi-Fi signal-strength characters couldn't be
represented (eg, LANG=C), the entire Wi-Fi SSID + signal strength
string would fail to convert, causing the Wi-Fi section of the
connection list to show up as a series of blank lines.
Fix this by testing beforehand whether the characters can convert, and
falling back to plain ASCII if not. (And also, fix the similar code in
nmt-newt-section.c, which got broken when nmt_newt_locale_from_utf8()
was changed to never return NULL.)
Also, for paranoia, represent the signal-strength strings via \nnn
escapes rather than actual UTF-8 data, to guarantee that they get
compiled to the expected values even if the source files get
re-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=733007
