Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
Since f9e4af2, parts of the configuration can be reloaded
by sending SIGHUP to NetworkManager. Add ExecReload option
to service file to support reloading by sending a signal.
Note that 'man 5 systemd.service' advices to use a blocking
command instead of a sending a signal. Later we should add a
D-Bus method to allow reloading synchronously. For now, this
is better then nothing.
https://mail.gnome.org/archives/networkmanager-list/2015-April/msg00042.html
No need to parse the subchannels if the spec list is empty.
This isn't actually an issue, because nm_match_spec_s390_subchannels()
was never called with empty spec list.
The configuration snippets are loaded in alphabetical order.
Fix the printed description to reflect that order. Otherwise,
NM logs at startup:
<info> Read config: /etc/NetworkManager/NetworkManager.conf and conf.d: 20-connectivity-fedora.conf, 10-ibft-plugin.conf
(process:6888): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GDBusProxy'
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x0000003148e50c70 in g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
#1 0x0000003148e50eaf in g_log (log_domain=log_domain@entry=0x3149a3b224 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3149a42690 "invalid unclassed pointer in cast to '%s'") at gmessages.c:1079
#2 0x0000003149a34171 in g_type_check_instance_cast (type_instance=type_instance@entry=0x6fc530, iface_type=<optimized out>) at gtype.c:4030
#3 0x00007ffff7d6b016 in nmdbus_settings_connection_call_get_settings_finish (proxy=0x6fc530, out_settings=out_settings@entry=0x7fffffffdbb8, res=res@entry=0x6fe150, error=error@entry=0x0)
at nmdbus-settings-connection.c:1303
#4 0x00007ffff7ce8813 in updated_get_settings_cb (proxy=<optimized out>, result=0x6fe150, user_data=user_data@entry=0x6fc650) at nm-remote-connection.c:588
#5 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe150 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#6 0x000000314a2df47c in reply_cb (connection=<optimized out>, res=0x6fe0e0, user_data=user_data@entry=0x6fe150) at gdbusproxy.c:2623
#7 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe0e0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#8 0x000000314a2d48cc in g_dbus_connection_call_done (source=<optimized out>, result=<optimized out>, user_data=user_data@entry=0x7fffec01a320) at gdbusconnection.c:5502
#9 0x000000314a27640d in g_simple_async_result_complete (simple=0x6e5f40 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#10 0x000000314a27647c in complete_in_idle_cb (data=0x6e5f40) at gsimpleasyncresult.c:775
#11 0x0000003148e49b6b in g_main_context_dispatch (context=0x687970) at gmain.c:3064
#12 0x0000003148e49b6b in g_main_context_dispatch (context=context@entry=0x687970) at gmain.c:3663
#13 0x0000003148e49f08 in g_main_context_iterate (context=0x687970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3734
#14 0x0000003148e4a232 in g_main_loop_run (loop=0x687a80) at gmain.c:3928
#15 0x00000000004136a1 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:632
(gdb)
We currently don't manage a veth inside a container despite we should because
it's an externally configured software interface and thus waits for IFF_UP.
Given veths are prevented from being managed outside of a container by an udev
rule anyway it's safe to lift the external IFF_UP requirement for them.
NM core uses nm-logging which is entirely configurable at runtime.
Other components use glib-logging, which can also be partly configured
via G_MESSAGES_DEBUG.
It makes sense to have a compile time option to enable some
logging statements that are only useful for heavy debugging.
For glib-logging, this is a way to enable/disable extra logging.
For nm-logging, we could alternatively configure a least log-level
that is enabled at compile time (that way, we could configure to prune all
LOGL_TRACE logging). While that might be useful (too), this gives
an alternative way to disable/enable logging.
Add a configure option --enable-more-logging and a NM_MORE_LOGGING define
for that.
If we don't find this useful after a while, we can simply remove it,
because our logging statements are not part of a "stable" behavior.
NM already has two kinds of assertions:
- g_assert*(), conditionally compiled via #ifndef G_DISABLE_ASSERT
- g_return*(), conditionally compiled via #ifndef G_DISABLE_CHECKS
In theory, one should be able to disable both asserts and NM should
still work correctly (and possibly more efficient). In practice,
hardly anybody is testing such a configuration and it might be broken.
Especially, we don't disable asserts for production builds, both because
of less test coverage and because it might reduce our ability to debug.
Add a new configure option --enable-more-asserts, which defines
NM_MORE_ASSERTS and nm_assert(). This is for expensive asserts,
that -- contrary to the asserts above -- are disabled by default.
This is useful for extended debugging.
For tests with assert-logging enabled, we already printed
the message with g_print(), instead of g_message().
We always want to print this value, because it is important
to reproduce a test failure. Hence, just (always) print
directly to stdout.
Also, add a leading newline, because the output was attached
to the previous line.
Some dual-band access points use the same BSSID in both the 5GHz
and 2.4GHz bands, so obviously frequency must be taken into account
when matching. But no AP should ever use the same SSID/BSSID pair
concurrently in the same band on different frequencies.
Some APs also dynamically channel hop when they detect interference,
or when they restart, they do so on a different channel after finding
the channel with the lowest interference. To assure that we don't
end up with stale scan list entries when the AP has switched to
another channel in the same band, fall back to band matching
when merging new scan results.
The only reason to allow lazy matching was to update a fake
current AP when its real scan result comes in. Now that NM
tracks the current AP based on the the supplicant's current
BSS, a fake current AP will be replaced when the real scan
result arrives. So it's pointless to update the fake one
when it'll just be removed soon.
Instead of keeping track of it internally, and attempting to fuzzy-match
access points and stuff, just use the supplicant's information. If the
supplicant doesn't know what AP it's talking to, then we've got more
problems than just NM code.
The theory here is that when starting activation, we'll use the given
access point from the scan list that the supplicant already knows about.
If there isn't one yet (adhoc, hidden, or AP mode) then we'll create
a fake AP and add it to the scan list.
Once the supplicant has associated to the AP, it'll notify about the
current BSS which we then look up in the scan list, and set
priv->current AP to that. If for some reason the given AP isn't yet
in our scan list (which often happens for adhoc/AP) then we'll just
live with the fake AP until we get the scan result, which should happen
very soon.
We don't need to do any fuzzy-matching to find the current AP because
it will either always be one the supplicant knows about, or a fake one
that the supplicant doesn't know about that will be replaced soon anyway.
The function names in linux-platform should get better prefixes
indicating whether they are related to libnl or nm objects.
Add a prefix _nlo_ for functions that operate on libnl objects.
