... and make the structs NMAuthSubject and NMAuthSubjectClass
opaque types.
I don't want to do this for all our types, only for a few prominent
GObject instances that we create a lot and that are really not expected
to ever be subclassed.
NMAuthSubject is such a candidate. It is really a very simple object
containing a few information bits about the authentication request.
It is not ever expected to be extended/inherited or become more
complex. No need to do a full-fledged private-data implementation.
Usually, our _GET_PRIVATE() macros cast away the const-ness of
the self argument -- also because they cannot do any better in
plain (gcc) C.
Now it is possible to preserve const-ness, it seems more correct to do so.
After all, the const should also help us not modifying arguments that are
not intended to be modified.
Although, the more important use of const is to signal that a function
promises not to modify an argument, like in memcpy(void*,const void*)
it's immediately clear which is source and destination. In C, a const
is anyway not enforcable, but can show intent.
Likewise for NM_IP6_CONFIG_GET_PRIVATE() and NMIP6Config.
We don't add such wrappers anywhere else, and I think they are not
desired style.
Also, keep the signal-id in a "gulong session_changed_id", instead of
guint.
With GObject, the object structure and class structure must be public
to be able to inherit from the type. As NMIP4Config is not inherited
(final), we don't need that and we don't expect ever needing that for
this type.
Already now, we want to have the priv pointer directly accessible via
self->priv. The main reason is improved debugging, another reason
is faster lookup.
Now with the struct private, we can directly embed the private data
inside NMIP4Config. This avoids storing the private data outside separately
inside the GObject which involves a small overhead.
It becomes more attractive to do so, as every NMDevice has a multitude of
these NMIP4Config instances.
And likewise for NMIP6Config.
We call the asynchrnous function mm_sim_send_pin() without taking a
reference on @self. During send_pin_ready() we must first check whether
the request was cancelled because self might be a dangling pointer at
this point.
Also, avoid leaking @error if the ctx is no longer valid.
Fixes: aa0b379699
When the IP status is IP_DONE and a DHCP transaction succeeds the
'dhcp4' and 'dhcp6' pending actions must be removed. Without this, a
temporary link loss just after the activation would cause a DHCP
restart and those actions would remain set, blocking the startup.
https://bugzilla.redhat.com/show_bug.cgi?id=1330893
If the device is disconnected, we should also disconnect the modem; and
while we disconnect the device we should clean the connection context.
Otherwise the modem will surprise us by emitting PREPARED signal when
the device is no longer PREPARED:
NetworkManager[28469]: <info> [1462383185.8714] (ttyACM1): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[28469]: <info> [1462383185.8715] (ttyACM1): modem state changed, 'registered' --> 'connecting' (reason: user-requested)
NetworkManager[28469]: <info> [1462383185.8716] device (ttyACM1): state change: deactivating -> disconnected (reason 'connection-removed') [110 30 38]
NetworkManager[28469]: <info> [1462383185.8759] (ttyACM1): modem state changed, 'connecting' --> 'disconnecting' (reason: user-requested)
NetworkManager[28469]: <warn> [1462383185.8937] (ttyACM1): failed to connect modem: Dial operation has been cancelled
(NetworkManager:28469): NetworkManager-wwan-CRITICAL **: modem_prepare_result: assertion 'state == NM_DEVICE_STATE_PREPARE' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7fffea31bc47 "NetworkManager-wwan", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcfc0) at gmessages.c:1086
1086 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4ebe643 in g_logv (log_domain=0x7fffea31bc47 "NetworkManager-wwan", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcfc0) at gmessages.c:1086
#1 0x00007ffff4ebe7bf in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1119
Python Exception <type 'exceptions.RuntimeError'> Cannot locate object file for block.:
#2 0x00007ffff2ce6dac in ffi_call_unix64#3 0x00007ffff2ce66d5 in ffi_call (cif=cif@entry=0x7fffffffd300, fn=<optimized out>, rvalue=0x7fffffffd230, avalue=avalue@entry=0x7fffffffd1d0) at ../src/x86/ffi64.c:522
#4 0x00007ffff51b55a5 in g_cclosure_marshal_generic_va (closure=0x555555b30cb0, return_value=0x0, instance=0x555555a8d360, args_list=<optimized out>, marshal_data=0x0, n_params=2, param_types=0x555555c2bb60) at gclosure.c:1600
#5 0x00007ffff51b4b37 in _g_closure_invoke_va (closure=closure@entry=0x555555b30cb0, return_value=return_value@entry=0x0, instance=instance@entry=0x555555a8d360, args=args@entry=0x7fffffffd5b8, n_params=2, param_types=0x555555c2bb60) at gclosure.c:864
#6 0x00007ffff51ce117 in g_signal_emit_valist (instance=instance@entry=0x555555a8d360, signal_id=signal_id@entry=168, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd5b8) at gsignal.c:3292
#7 0x00007ffff51cf2e8 in g_signal_emit_by_name (instance=instance@entry=0x555555a8d360, detailed_signal=detailed_signal@entry=0x7fffea074cdd "prepare-result") at gsignal.c:3479
#8 0x00007fffea011fd3 in connect_context_step (self=self@entry=0x555555a8d360 [NMModemBroadband]) at nm-modem-broadband.c:529
#9 0x00007fffea01264d in connect_ready (simple_iface=<optimized out>, res=<optimized out>, self=0x555555a8d360 [NMModemBroadband]) at nm-modem-broadband.c:378
#10 0x00007ffff546a297 in g_simple_async_result_complete (simple=0x7fffe00104e0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801
#11 0x00007fffe9d82fec in connect_context_complete_and_free (ctx=ctx@entry=0x555555c52f60) at mm-modem-simple.c:93
#12 0x00007fffe9d83155 in simple_connect_ready (self=0x7fffdc00b9f0 [MMModemSimple], res=0x7fffdc004410, ctx=0x555555c52f60) at mm-modem-simple.c:159
#13 0x00007ffff547af93 in g_task_return_now (task=0x7fffdc004410 [GTask]) at gtask.c:1106
#14 0x00007ffff547b62e in g_task_return (task=0x7fffdc004410 [GTask], type=<optimized out>) at gtask.c:1164
#15 0x00007ffff54d4239 in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x7fffdc004410) at gdbusproxy.c:2570
#16 0x00007ffff547af93 in g_task_return_now (task=0x7fffdc004340 [GTask]) at gtask.c:1106
#17 0x00007ffff547b62e in g_task_return (task=0x7fffdc004340 [GTask], type=<optimized out>) at gtask.c:1164
#18 0x00007ffff54c8c9f in g_dbus_connection_call_done (source=<optimized out>, result=0x555555a60920, user_data=0x7fffdc004340) at gdbusconnection.c:5702
#19 0x00007ffff547af93 in g_task_return_now (task=0x555555a60920 [GTask]) at gtask.c:1106
#20 0x00007ffff547afc9 in complete_in_idle_cb (task=0x555555a60920) at gtask.c:1120
#21 0x00007ffff4eb7d7a in g_main_context_dispatch (context=0x555555a4a000) at gmain.c:3152
#22 0x00007ffff4eb7d7a in g_main_context_dispatch (context=context@entry=0x555555a4a000) at gmain.c:3767
#23 0x00007ffff4eb80b8 in g_main_context_iterate (context=0x555555a4a000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#24 0x00007ffff4eb838a in g_main_loop_run (loop=0x555555a48780) at gmain.c:4032
#25 0x00005555555aebf2 in main (argc=1, argv=0x7fffffffdc48) at main.c:477
(gdb)
If libmm invokes callbacks after the connect context has been disposed
we should just ignore them. Fixes crash on dereferencing already freed
connect context (due to explicit disconnection while the modem is
connecting):
NetworkManager[29074]: <info> [1462383917.8718] (ttyACM1): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.8719] (ttyACM1): modem state changed, 'registered' --> 'connecting' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.8720] device (ttyACM1): state change: deactivating -> disconnected (reason 'connection-removed') [110 30 38]
NetworkManager[29074]: <info> [1462383917.8758] (ttyACM1): modem state changed, 'connecting' --> 'disconnecting' (reason: user-requested)
NetworkManager[29074]: <warn> [1462383917.8909] (ttyACM1): failed to connect modem: Dial operation has been cancelled
(NetworkManager:29074): NetworkManager-wwan-CRITICAL **: modem_prepare_result: assertion 'state == NM_DEVICE_STATE_PREPARE' failed
NetworkManager[29074]: <info> [1462383917.8912] (ttyACM1): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.8913] (ttyACM1): modem state changed, 'registered' --> 'connecting' (reason: user-requested)
NetworkManager[29074]: <info> [1462383917.9693] (ttyACM1): modem state changed, 'connecting' --> 'registered' (reason: user-requested)
Program received signal SIGSEGV, Segmentation fault.
connect_ready (simple_iface=<optimized out>, res=0x7fffe0009200, self=0x555555a8d670 [NMModemBroadband]) at nm-modem-broadband.c:329
329 if (!ctx->first_error) {
(gdb) bt
#0 0x00007fffea01272a in connect_ready (simple_iface=<optimized out>, res=0x7fffe0009200, self=0x555555a8d670 [NMModemBroadband]) at nm-modem-broadband.c:329
#1 0x00007ffff546a297 in g_simple_async_result_complete (simple=0x7fffe0009200 [GSimpleAsyncResult]) at gsimpleasyncresult.c:801
#2 0x00007fffe9d82fec in connect_context_complete_and_free (ctx=ctx@entry=0x7fffdc00c550) at mm-modem-simple.c:93
#3 0x00007fffe9d83155 in simple_connect_ready (self=0x7fffdc00c960 [MMModemSimple], res=0x555555a7c2b0, ctx=0x7fffdc00c550) at mm-modem-simple.c:159
#4 0x00007ffff547af93 in g_task_return_now (task=0x555555a7c2b0 [GTask]) at gtask.c:1106
#5 0x00007ffff547b62e in g_task_return (task=0x555555a7c2b0 [GTask], type=<optimized out>) at gtask.c:1164
#6 0x00007ffff54d4239 in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x555555a7c2b0) at gdbusproxy.c:2570
#7 0x00007ffff547af93 in g_task_return_now (task=0x7fffdc004470 [GTask]) at gtask.c:1106
#8 0x00007ffff547b62e in g_task_return (task=0x7fffdc004470 [GTask], type=<optimized out>) at gtask.c:1164
#9 0x00007ffff54c8c9f in g_dbus_connection_call_done (source=<optimized out>, result=0x7fffe00036f0, user_data=0x7fffdc004470) at gdbusconnection.c:5702
#10 0x00007ffff547af93 in g_task_return_now (task=0x7fffe00036f0 [GTask]) at gtask.c:1106
#11 0x00007ffff547afc9 in complete_in_idle_cb (task=0x7fffe00036f0) at gtask.c:1120
#12 0x00007ffff4eb7d7a in g_main_context_dispatch (context=0x555555a4a000) at gmain.c:3152
#13 0x00007ffff4eb7d7a in g_main_context_dispatch (context=context@entry=0x555555a4a000) at gmain.c:3767
#14 0x00007ffff4eb80b8 in g_main_context_iterate (context=0x555555a4a000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#15 0x00007ffff4eb838a in g_main_loop_run (loop=0x555555a48780) at gmain.c:4032
#16 0x00005555555aebf2 in main (argc=1, argv=0x7fffffffdc78) at main.c:477
(gdb)
Like we do on RHEL. The package-split was originally necessary because
installing a pre-up dispatcher script would block activation (even if there
were no relevant route files.
Even if we have now the no-wait.d/ directory for dispatchers, still
split the package. It makes sense to have the routing-rules in a
separate RPM.
For contrib/rpm, we don't properly obsolete an older version of
NetworkManager package and thus the upgrade path will be broken.
This is required to add objects in the "Types and Values" section and
in the API index. Later, we may want to add useful content in those
empty comments.
nm-core-types.h and nm-types.h contain the actual definition of types
and gtk-doc won't generate a "Implemented interfaces" section if they
are not included.
https://bugzilla.gnome.org/show_bug.cgi?id=765983
Once we start with dispose, we certainly don't want to process any platform
events for the device anymore.
Previously, we disconnect those handlers only later during dispose, so it's
not clear that we would not receive a device_ipx_changed signal after _cleanup_generic_pre().
Fix this possible (or actual) bug.
Since commit a47c13a7a2, update_ip4_config() re-schedules
itself in case activate_stage5_ip4_config_commit is pending. Thus, there is no need to
cancel any queued queued_ip4_config_id.
Also as that does not properly fix the issue unlike a47c13a7a.
update_ip4_config() and update_ip6_config() are called from nm_device_capture_initial_config().
At that point, we don't expect any activation-source scheduled, thus the "if" should not
not be hit anyway.
So, this patch should actually make no difference, but it seems clearer
to me. Also, because it would be a bug to re-schedule the idle handler
that is already pending, but from inspecting nm_device_capture_initial_config()
it is not immediately clear that this cannot be the case.
Just like `nmcli device connect` only allows one argument, don't allow
multiple device arguments for reapply.
Allowing multiple device names makes it more complicated to add
additional options to the command. For example, it would be useful
to have a
nmcli device reapply eth0 connection id other-connection
but when allowing multiple device names, it gets more complicated in
documentation, command line parsing and bash completion.
Note that the user can achieve a very similar outcome by using the
shell:
for DEV in eth0 eth1 eth2; do
nmcli device reapply $DEV &
done
wait
argubaly, this doesn't report the exit status properly. To properly
handle that would require more effort. Also, it is somewhat less
efficient, but well.
This is an API change, however it is very new API that probably nobody
is using much. Also, the documentation (man nmcli) didn't mention the
possibility to pass multiple device names.
To allow for trailing whitespace, we don't need to copy and trunacate
the input string. g_ascii_strtoll() conveniently returns the location via
the endptr argument.
Make DHCPv6 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Make DHCPv4 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Introduce the nm_device_ip_method_failed() function to check if the
failure of an IP method should cause the activation to fail, and use
it where appropriate.
http://bugzilla.gnome.org/show_bug.cgi?id=741347
